像 谷歌 一 样 部 署 自己 的 应 


当 我 发 现 这 上 面 
贡献 者 。 他 在 研究 生 毕 业 以 


， 这 是 很 多 软件 工程 师 的 梦想 。Docker 的 


最 近 ， 我 又 欣喜 地 发 现 ， 这 系列 文章 以 及 


便 更 好 地 使 


近年 来 ，Docker 迅 速 风 摩 了 云 计算 世界 ， 但 是 专门 针对 Docker 的 技术 实现 进行 深入 分 析 的 文章 却 相对 较 少 。 
备 全 局 的 视角 ， 才 能 深入 浅 出 地 找到 源码 中 的 脉络 。 


码 的 解析 ， 需 要 对 整个 Docker 设 计 : 


宏 亮 的 这 本 《Docker 源 码 分 析 》， 恰 如 其 时 的 出 现 ， 弥 补 了 这 个 空白 ， 


在 崇尚 源码 至 上 的 工程 师 文 化 里 ， 文 档 介 绍 、 发 布 会 材料 都 是 苑 
分 析 ， 你 就 可 以 轻松 地 站 在 巨人 的 肩膀 上 。 


ROSAS T YEA 


很 高 兴 看 到 国内 这 么 快 就 出 版 源码 分 析 的 书籍 。 对 于 所 有 想 在 Doc 


同 推动 Docker 的 发 展 。 


值得 自豪 的 是 ， 就 在 Docker 茵 勃发 展 之 际 ， 第 一 本 详尽 剖析 Docker 源 码 的 著作 出 自 


本 书 在 每 章 宏 观 的 流程 梳理 背后 都 伴随 有 更 加 细致 深入 的 源码 分 析 。 无 论 读者 是 只 想 了 解 使 


这 本 书 从 源码 的 角度 对 Docker 的 实现 原理 进行 了 深入 的 探讨 和 细腻 的 讲解 ， 将 当前 热门 的 容器 技术 的 背后 机 理 讲解 得 深入 浅 出 明白 


Ss 


1% 


TER 


很 多 人 的 梦 。 


| 登 的 “Docker 源 码 分 析 ” 系 列 文章 的 作者 居然 是 我 们 
后 投身 到 了 创业 公司 DaoCloud， 去 为 Docker 的 梦想 开创 美好 的 未 来 。 


后 续 章节 即将 正式 出 版 成 书 ， 有 机 会 同 更 多 的 Docker, 


课程 组 的 研究 生 助教 孙 宏 亮 时 ， 惊 喜之 情 溢 了 


FEK. 


户 、 开 发 者 、 学 习 者 见面 


自从 InfoQ 推 出 Docker 系 列 文章 ， 作 为 操作 系统 课程 教师 的 我 一 直 在 学 习 并 关注 Docker 的 区 壮 成 长 。 


宏 亮 对 Docker 的 理解 十 分 深刻 ， 他 本 人 是 Docker 的 积极 拥护 者 、 倡 导 者 和 


。 本 书 通过 分 析 解 读 Docker 源 码 ， 让 读者 了 解 Docker 的 内 部 结构 和 实现 ， 以 


这 一 方面 


对 了 


希望 参与 到 Docker 社 区 、 


Docker 有 更 深刻 的 理解 ， 能 够 更 好 地 使 


Docker 已 经 是 一 个 成 长 2 


EAR 


读 源码 ， 才 能 深刻 理解 软件 背后 的 原理 。 与 所 有 其 他 软件 一 样 ， 读 源码 并 不 是 学 习 Docker 最 快 的 途径 ， 


参与 代码 贡献 或 构建 自己 的 Docker 应 


89, 


er 方 下 


E 


介 和 想 晋 升 为 高 端 


国人 之 手 。 


或 者 开发 Docker。 


时 间 的 云 计 算 技 术 ， 它 正在 以 惊人 的 速度 在 全 球 范 


国内 扩张 


Docker， 还 是 抱 着 深入 理解 Docker 并 参与 社 


己 的 “ 疆 士 ”。 我 作为 Docker 中 国 


Docker。 该 书 的 内 容 组 织 深 入 浅 出 ， 表 述 准确 到 位 ， 有 大 量 流程 图 和 代码 片段 帮助 读者 理解 Docker 各 个 功能 模块 的 流程 ， 是 学 习 Docker 开 源 系统 的 良师益友 。 


硅 黎 旦 ， 浙 江 大 学 计算 机 学 院 教授 


由 于 Docker 技 术 变 化 很 快 ， 源 码 分 析 很 快 会 跟 不 上 版 本 发 展 ， 另 一 方面 ， 对 源 代 


环境 的 读者 来 说 ， 应 是 一 本 案头 必 备 书籍 。 


一 一 王 兴 宇 ， 《Linux 中 国 》 创 始 人 


但 是 如 果 有 人 通读 


户 的 读者 ， 都 值得 阅读 本 书 ， 也 希望 通过 《Docker 源 码 分 析 》 一 书 ， 可 以 诞生 更 多 的 社区 贡献 者 ， 共 


一 一 黄强 ， 华 为 Docker Committer 


区 


区 的 


透彻 。 无 论 是 Docker 


发 的 心态 ， 本 书 都 值得 一 读 。 


一 一 胡 科 平 ， 华 为 Docker Committer 


的 用 户 还 是 开发 者 ， 通 过 阅读 本 书 都 可 以 对 


一 一 雷 继 党 ， 华 为 Docker Committer 


发 者 ， 非 常 希望 能 看 到 有 一 本 书 详细 地 告诉 我 ，Docker 的 每 一 个 细 


节 是 如 何 实现 的 。 所 以 当 我 在 InfoQ 上 看 到 宏 亮 的 “Docker 源 码 分 析 ” 专 栏 时 眼前 一 亮 。 今 天 ， 它 终于 汇编 成 书 摆 在 你 我 的 眼前 。 我 希望 你 能 在 这 本 书 上 学 到 更 多 Docker 技 术 的 精髓 思想 ， 在 实战 Docker 


技术 时 可 以 运用 自如 ! 


我 家 里 的 书柜 中 至 今 仍然 保留 着 一 本 《Linux 内 核 完全 注释 》， 它 伴随 我 很 长 一 段 时 间 ， 使 我 


Docker， 还 是 掌握 Go 语言 ， 都 是 非常 好 的 一 手 资源 。 雷 锋 不 常 有 ， 大 家 要 支持 ! 


三 年 前 ， 我 在 VMware 负责 Cloud Foundry 这 一 款 
上 出 现 了 一 个 专门 从 底层 模块 和 源码 的 角度 ， 对 Cloud Foundry 做 深度 剖析 | 


经 过 一 番 “ 人 肉 搜索 ”， 我 非常 惊奇 的 发 现 ， 这 一 系列 了 
系 的 SEL 实 验 室 ， 投 入 了 精锐 的 师资 力量 ， 从 事 分 布 式 系统 和 新 一 代 PaaS 的 研究 工作 。 宏 亮 初 入 浙江 大 学 ， 就 在 这 样 的 氛 轩 


宏 亮 在 CSDN 上 的 系列 文章 ， 主 打 “源码 分 析 ”， 这 正 是 当时 开源 社区 内 比较 缺少 的 内 容 。 提 笔 写 “ 源 码 分 析 ”， 需 要 一 定 的 
的 逻辑 ， 从 中 抽 丝 拨 茧 、 概 括 精华 ， 这 是 一 份 非常 辛苦 的 工作 。 而 且 ， 分 析 源 码 也 需要 一 些 “ 挑 战 权威 ”的 精神 ， 不 仅仅 是 简 和 


题 。 


一 一 肖 德 时 ， 数 人 科技 CTO 


FE 
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之 后 ， 当 我 拿 到 宏 亮 的 《Docker 源 代码 分 析 》 


序 


源 PaaS 产 品 在 中 


F 贷 的 作者 孙 宏 亮 ， 


然 是 浙江 大 学 计算 系 的 一 入 


FA 


究 生 。 当 时 ，VMware 跟 浙江 大 学 在 Cloud Foundry 方 画 


稿 ， 昨 日 又 重 现 。 这 本 书 无 论 是 对 学 习 


一 一 赵 胸 ，VisualOps 创 始 人 


国 的 开发 者 社区 和 人 生态 系统 建设 工作 。 当 时 关于 Cloud Foundry 的 中 文 文档 非常 少 ， 更 不 用 说 有 深度 的 技术 干货 了 ， 所 以 当 CSDN 
的 系列 博客 文章 时 ， 一 下 子 就 引起 了 我 的 注意 。 


有 比较 深入 的 合作 ， 浙 大 计算 机 


下 开始 了 他 的 研究 生 求 学 生 汝 


， 应 当 说 是 非常 幸运 的 。 


从 数 十 万 行 代码 中 整理 出 清晰 


气 ， 阅 读 源码 需要 耗费 大 量 的 精力 ， 需 
的 代码 解析 ， 更 需要 提炼 出 


自己 的 观点 ， 甚 至 敢于 发 现 和 纠正 一 些 已 有 的 问 


在 源码 分 析 方面 ， 宏 亮 充 分 体现 了 “初生 牛犊 不 怕 虎 ”的 精神 ， 非 常 详 细 地 剖析 了 当时 Cloud Foundry 的 几 个 主要 模块 ， 条 理 清晰 ， 技 术 分 析 准 确 到 位 。 宏 亮 这 一 系列 文章 帮助 了 包括 一 线 互联 网 公司 


在 内 的 许多 企业 了 解 、 认 识 和 最 终 使 用 C 


Docker 的 热潮 


从 去 年 开始 ， 


Docker 的 一 些 展望 。 那 次 大 会 是 一 个 很 重要 的 里 程 碑 ， 在 那 之 后 ， 宏 亮 开始 深入 研究 Docker 的 底 


iml 


始 波及 中 国 开发 者 社区 。 我 有 幸 跟 宏 亮 一 起 在 CSDN 主 办 的 第 一 


oud Foundry， 宏 亮 也 借 此 英 定 了 他 在 PaaSs 社 区 的 “江湖 地 位 ”。 


届 Container 技 术 大 会 上 发 表 联 合 
层 实现 ， 并 在 InfoQ 连 载 “Docker 源 码 分 析 ” 系 列 文章 。 


FE 题 演讲 ， 向 来 宾 介绍 Cloud Foundry 内 部 的 容器 技术 实现 ， 以 及 对 


对 Paas 平 台 的 研究 越 深入 ， 越 能 够 发 现 和 体会 Docker 对 开发 和 运 维 的 价值 。 如 果 说 当初 的 Cloud Foundry 模 块 和 源码 分 析 文 章 ， 是 读 研 期 间 的 学 习 笔记 ， 那 这 次 宏 亮 的 《Docker 源 码 分 析 》， 则 是 一 


个 经 过 了 深思 熟 虑 、 系 统 性 、 结 构 化 的 工作 。Docker 开 源 项 
Swarm、Machine 和 Compose 这 三 个 模块 的 开发 进展 做 了 紧密 的 追踪 。 


这 是 一 本 从 架构 和 代码 角度 讲解 Docker 底 


层 实现 的 技术 图 书 ， 我 从 连载 第 一 篇 开始 就 对 这 个 系列 的 文章 保持 了 紧密 的 关注 ， 也 


发 展 速度 非常 快 ， 这 次 在 文章 连载 内 容 的 基础 上 出 书 ， 为 了 保证 内 容 的 准确 性 和 时 效 性 ， 宏 亮 补充 了 大 量 Docker 最 新 项 目的 内 容 ， 特 别 是 对 


睹 了 宏 亮 在 后 期 整理 加 工 成 书 过 程 中 的 辛勤 努力 。 在 《Docker 源 码 分 


析 》 成 书 付 梓 出 版 之 际 ， 非 常 幸运 ， 能 够 为 宏 亮 写 着 一 篇 推荐 序 。 这 本 书 非常 适合 以 下 三 类 读者 学 习 和 阅读 。 


“ 希望 以 Docker 容 器 交付 软件 的 程序 员 。 


Docker 是 未 来 互联 网 软件 的 交付 件 ， 这 件 事 随 着 OCP 标 准 的 制定 ， 正 在 逐渐 成 为 事实 。 程 序 员 和 运 维 工 程 师 都 需要 了 解 Docker 的 工作 方式 ， 尤 其 是 Docker 镜 像 的 结构 ， 软 件 通过 Dockerfile 打 包 时 的 


优化 方式 等 ， 这 些 内 容 在 本 书 中 都 有 非常 详细 的 阐述 。 


* Docker 化 云 计算 平台 的 建设 者 和 维护 者 。 


Docker 公 司 在 今生 


F 的 全 球 开发 者 大 会 上 提出 了 “Production Ready" 的 


号 ， 有 越 来 越 多 的 互联 网 公司 和 传统 企业 采 


Docker 来 构建 开发 、 


测试 和 运 维 平台 。 Docker 在 网 络 、 存 储 、 安 全 等 领域 的 细 


节 ， 是 平台 建设 者 和 维护 者 必须 深入 了 解 的 部 分 ， 这 些 领 域 还 在 不 断 变化 ， 新 的 项 目 也 层出不穷 ， 但 本 书 对 网 络 、 存 储 和 安全 的 基本 知识 和 概念 ， 做 了 非常 清晰 的 介绍 ， 也 深入 到 了 底层 实现 的 代码 。 


:Go 语言 程序 员 。 


即使 不 在 项 目 中 使 


员 亲 身体 验 特大 型 项 目 中 Go 语言 的 威力 ， 以 及 实战 场景 中 Golang 模 式 和 功能 的 用 法 。 


Docker， 本 书 也 能 够 为 Go 语言 程序 员 带 来 帮助 。 Docker 项 目 中 大 量 采 


了 Go 语言 ， 尤 其 是 在 处 理 并 发 场景 时 ，Docker 对 Go 语言 的 运 


最 后 ， 预 祝 宏 亮 在 Docker 的 学 习 和 工作 中 再 创 佳绩 ， 也 希望 读者 可 以 从 本 书 收获 知识 ， 开 沙眼 界 。 


Docker 是 什么 


Docker 从 2013 年 诞 4 


E， 短 短 两 


Docker 官 方 如 此 描述 Docker: 
的 开放 平台 ， 从 而 可 以 便捷 地 构建 、 迁 移 与 运行 分 布 式 应 用 。 


多 年 来 ，IT 行 业 中 


实践 过 程 中 ， 开 发 与 运 维 分 离 的 方式 难免 存在 弊病 ， 两 者 职责 的 过 分 清晰 导致 软件 效率 的 降低 。 
矶 少 软件 运行 环境 的 认 知 ， 而 运 维 人 员 对 软件 逻辑 所 知 甚 少 。 


由 ， 还 是 因为 开发 人 员 : 


Docker 无 疑 是 DevOps 大 潮 中 最 
另外 ，Docker 的 镜像 技术 利 


发 与 运 维 一 直 是 两 个 界限 清晰 的 词 


。 开 发 工程 师 专门 从 寺 


a 
nii 


FRSIBISUCESSEKITPEIEBIPRGESREZT, SCISTSCRBSIPIAR EI ARAIRE. SAU, DockerzftA, Docker T 11A? 


可 谓 出 神 入 化 。 本 书 可 以 帮助 Go 语言 程序 


LE 


201547 H138 


"Build, Ship, Run.An open platform for distributed applications for developers and sysadmins”。 换 言 之 ，Docker 为 开发 者 与 系统 管理 者 提供 了 分 布 式 应 


联合 文件 系统 的 优势 ， 


实践 价值 的 不 二 法 宝 。Docker 从 Linux 内 核 的 角度 出 发 ， 属 于 轻 量 级 虚拟 化 技术 ， 有 能 力 秒 级 提供 应 


下 至 上 打包 系统 软件 、 系 统 环境 以 及 软件 程序 ， 将 运行 环境 与 应 


参 着 分 布 式 系统 的 流行 ， 


软件 的 开发 工作 ， 最 终 交 付 软 件 代码 ; 运 维 工程 师 则 部 署 前 者 交付 的 软件 ， 并 接管 软件 的 运行 与 管理 。 然 而 ， 在 长 时 间 的 
系统 规模 越 来 越 大 ， 软 件 越 来 越 复杂 ， 系 统 环境 配置 暴露 的 问题 层出不穷 。 究 其 缘 


在 这 样 的 背景 下 ，DevOps 横 空 出世 ， 提 倡 开发 与 运 维 不 可 分 割 ， 协 调 并 进 。 


隔离 环境 ， 完 成 云 计算 时 代 分布 式 应 


Dockerfile， 极 大 地 简化 镜像 的 复杂 性 ， 并 为 镜像 的 转移 与 重新 构建 提供 了 可 能 性 。 


本 书 的 内 容 


本 书 是 一 本 引导 读者 了 解 Docker 实 现 原理 的 技术 普及 书 。 笔 者 一 


软件 或 系统 的 本 质 。 


本 书 的 内 容 主要 集中 于 3 个 部 分 : Docker 的 架构 ，Docker 


Docker 提 供 轻便 的 资源 分 配方 式 ， 解 决 应 
家 国际 IT 巨头 也 纷纷 宣布 支持 Docker， 这 一 切 更 是 让 全 球 IT 人 z 


运行 与 系统 环境 的 依赖 ， 


尔 合 应 


坚信 ， 了 解 软件 或 者 系统 最 直接 、 最 透彻 的 方式 就 是 研读 它们 的 源码 。 


的 模块 ，Docker 的 三 驾 马 车 Swarm、Machine 以 及 Compose。 


第 一 部 分 ， 主 要 从 宏观 的 角度 和 读者 一 起 领略 Docker 的 架构 设计 ， 并 初步 介绍 架构 中 各 模块 的 职责 。 


第 二 部 分 是 本 书 的 


体 部 分 ， 


针对 Docker 中 多 个 


要 的 模块 进行 : 


体 深 入 分 析 ， 包 括 : Docker Client, Docker Daemon, Docker Server、Docker 网 络 、Docker 镜 像 、 


的 第 一 需求 “隔离 ”。 


程序 灵活 地 结合 ， 快 速 运行 Docker 化 的 应 用 程序 。 同 时 ， 可 读 性 极 强 的 


跨 节 点 迁移 的 鸿沟 ， 种 种 特性 都 表明 Docker 几 乎 就 是 为 “ 云 计 算 ” 而 生 的 。 如 今 ，Docker 社 区 不 断 扩 大 并 健康 发 展 ， 多 
上 对 Docker 的 未 来 充满 信心 。 


“源码 即 文档 ”也 是 鼓励 开发 者 能 更 多 地 从 源码 的 角度 去 学 习 


Docker 容 器 等 。 读 者 可 


以 发 现 ，Docker 的 模块 之 间 耦 合 度 非 常 低 ， 很 适合 循序 渐进 ， 层 层 深入 。 第 2 章 至 第 8 章 主要 从 Docker 软 件 的 架构 入 手 ， 勾 勒 骨 架 ; 第 9 章 至 第 11 章 重点 讨论 Docker 镜 像 技术 ， 夯 实 基础 ; 第 12 章 至 第 14 章 


则 进一步 分 析 Docker 容 器 的 始末 ， 


第 三 部 分 介绍 Docker 生 : 


态 三 驾 


阐述 本 质 。 


Docker 生 态 圈 中 其 他 功能 强大 的 软件 。 


马车 Swarm、Machine、Compose。Docker 拥 有 强大 的 单机 能 


希望 本 书 能 够 让 读者 最 大 化 地 感受 Docker 的 神奇 与 魅力 。 


关于 勘误 


由 于 时 间 与 水 平 都 比较 有 限 ， 


因此 本 书 难免 会 存在 一 些 纶 泼 和 


， 三 驾 马 车 可 以 很 好 地 补充 Docker 的 跨 主机 能 力 以 及 部 署 能 力 。 读 者 可 以 通过 第 15 章 至 第 17 章 感受 


错误 。 如 果 读 者 发 现 了 问题 ， 请 及 时 与 我 联系 。 我 也 会 在 本 书后 续 的 版 本 中 加 以 改正 。 我 的 邮箱 是 : allen.sun@daocloud.io。 我 非常 希 


望 和 大 家 一 起 学 习 与 讨论 Docker， 并 共同 推动 Docker 在 社区 的 发 


致谢 


最 后 ， 向 本 书 编写 过 程 中 给 予 我 
们 ， 是 他 们 在 我 求学 过 程 中 给 予 无 私 的 指引 与 帮助 。 感 澳 我 的 同 寻 


eo 


做 了 很 多 沟通 与 协调 工作 。 最 后 ， 还 


巨大 帮助 的 人 们 表示 最 诚挚 的 感谢 。 感 谢 我 的 父母 ， 没 有 他 们 的 鼓励 和 支持 ， 此 书 不 可 能 在 如 此 短 的 时 间 内 完成 。 感 谢 我 的 母校 浙江 大 学 以 及 SEL 实 验 室 的 老师 与 同学 


能 中 祥 ， 是 他 在 本 书 编写 过 程 中 提出 了 很 多 宝贵 的 建议 ， 尤 其 在 Machine 和 Compose 部 分 。 感 谢 我 的 同事 喻 勇 和 冯 钊 ， 他 们 为 本 书 的 编写 


感谢 华章 公司 的 编辑 们 ， 她 们 认真 细致 的 工作 ， 使 本 书 以 完美 的 形式 展现 给 各 位 读者 。 
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第 1 章 ”Docker 架 构 


FGitHub 网 站 上 ， 并 遵从 Apache 2.0 协 议 。 
层 的 虚拟 化 实现 资 


1.1 引言 
内 ，Docker 还 是 一 个 开源 项 目 ， 整 个 项 目 基 于 Go 语言 开发 ， 代 码 托管 了 
核 特 性 命名 空间 (namespaces) 及 控制 组 (cgroups) 等 为 容器 提供 隔离 的 运行 环境 。Docker 借 助 操作 系统 
而 大 大 提高 了 资源 利用 率 ， 并 


机 共享 同一 个 操作 系统 ， 不 会 有 额外 的 操作 系统 开销 。 这 样 的 优势 很 明显 ， 因 


F6 月 推出 了 


Docker 是 Linux 平 台 上 的 一 款 轻 量 级 虚拟 化 容器 的 管理 引擎 。 在 全 球 范 
户 在 容器 内 部 快速 自动 化 部 署 应 用 ， 并 利用 Linux 内 
的 运行 有 很 大 的 区 另 


er 容器 在 运行 时 与 虚拟 
性 能 。 
的 时 间 里 迅速 获得 了 诸多 厂商 的 青睐 ， 其 中 更 是 包括 Google、Microsoft、VMware 等 行业 领航 者 。Google 在 2014 征 
F8 月 Microsoft 则 宣布 Azure 上 支持 Kubernetes， 随 后 传统 虚拟 化 巨头 VMware 宣布 与 Docker 强 强 合作 。2014 年 9 月 中 旬 ，Docker 更 是 获得 4000 


，Docker 容 器 与 宿 3 


前 ，Docker 可 以 帮助 


源 的 隔离 ， 因 此 Dock 
且 提 升 了 MO 等 方面 的 


众多 新 颖 的 特性 以 及 项 目 本 身 的 开放 性 ， 导 致 Docker 在 不 到 两 
的 调度 管理 ， 而 201 和 和 


Kubernetes， 宣 布 支持 Docker 容 器 
的 发 展 。 
目前 ，Docker 的 前 景 被 普遍 看 好 。 未 来 的 云 计 算 领 域 乃至 整个 IT 领域 ，Docker 都 必 将 扮演 不 可 或 缺 的 角色 。 为 了 帮助 大 家 更 好 地 认识 Docker、 理 解 Docker 并 掌握 Docker， 本 书 从 Docker 源 码 的 角度 


机 (VM) 


» 


年 


万 美元 的 C 轮 融资 ， 以 推动 分 布 式 应 
章 主要 介绍 Docker 架 构 。 


出 发 ， 详 细 介 绍 Docker 的 架构 、Docker 的 运行 以 及 Docker 的 特性 。 本 章 3 


本 书 关于 Docker 的 分 析 均 基于 Docker 1.2.0 版 本 的 源码 。 


本 章 目的 是 在 理解 Docker 源 码 的 基础 上 分 析 Docker 架 构 ， 分 析 过 程 


要 按照 以 下 三 个 部 分 进行 : 


' Docker 的 总 架构 图 。 
* Docker 架 构 内 部 各 模块 功能 与 实现 的 分 析 。 
“ 通过 具体 的 Docker 命 令 ， 曾 述 Docker 的 运行 流程 。 
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FGitHub 网 站 上 ， 并 遵从 Apache 2.0 协 议 。 
层 的 虚拟 化 实现 资 


， 整 个 项 目 基于 Go 语言 开发 ， 代 码 托管 
及 控制 组 (cgroups) 等 为 容器 提供 隔离 的 运行 环境 。Docker 借 助 操作 系统 
销 。 这 样 的 优势 很 明显 ， 因 而 大 大 提高 了 资源 利用 率 ， 并 


11 引言 
内 ，Docker 还 是 一 个 开源 项 


核 特性 命名 空间 (namespaces 
机 共享 同一 个 操作 系统 ， 不 会 有 额外 的 操作 系统 


Docker 是 Linux 平 台 上 的 一 款 轻 量 级 虚拟 化 容器 的 管理 引擎 。 在 全 球 范 | 
Linux 内 


前 ，Docker 可 以 帮助 用 户 在 容器 内 部 快速 自动 化 部 署 应 用 ， 并 利 
源 的 隔离 ， 因 此 Docker 容 器 在 运行 时 与 虚拟 机 (VM) 的 运行 有 很 大 的 区 别 ，Docker 容 器 与 宿 3 
且 提 升 了 I/O 等 方面 的 性 能 。 
众多 新 颖 的 特性 以 及 项 目 本 身 的 开放 性 ， 导 致 Docker 在 不 到 两 年 的 时 间 里 迅速 获得 了 诸多 厂商 的 青睐 ， 其 中 更 是 包括 Google、Microsoft、VMware 等 行业 领航 者 。Google 在 2014 年 6 月 推出 了 
Kubernetes， 宣 布 支持 Docker 容 器 的 调度 管理 ， 而 2014 年 8 月 Microsoft 则 宣布 Azure 上 支持 Kubernetes， 随 后 传统 虚拟 化 巨头 VMware 宣布 与 Docker 强 强 合作 。2014 年 9 月 中 旬 ，Docker 更 是 获得 4000 
的 发 展 。 
色 。 为 了 帮助 大 家 更 好 地 认识 Docker、 理 解 Docker 并 掌握 Docker， 本 书 从 Docker 源 码 的 角度 


万 美元 的 C 轮 融资 ， 以 推动 分 布 式 应 
目前 ，Docker 的 前 景 被 普遍 看 好 。 未 来 的 云 计算 领域 乃至 整个 IT 领 域 ，Docker 都 必 将 扮演 不 可 或 缺 的 
章 主要 介绍 Docker 架 构 。 


出 发 ， 详 细 介 绍 Docker 的 架构 、Docker 的 运行 以 及 Docker 的 特性 。 本 章 3 


本 书 关 于 Docker 的 分 析 均 基于 Docker 1.2.0 版 本 的 源码 。 
本 章 目的 是 在 理解 Docker 源 码 的 基础 上 分 析 Docker 架 构 ， 分 析 过 程 主要 按照 以 下 三 个 部 分 进行 : 


“ Docker 的 总 架构 图 。 
* Docker 架 构 内 部 各 模块 功能 与 实现 的 分 析 。 


- 通过 具体 的 Docket 命 令 ， 益 述 Docket 的 运行 流程 。 


目 清晰 的 源码 结构 使 得 Docker 的 学 习 成 本 并 不 高 。 换 言 之 ，Docker 源 码 的 学 习 
户 通过 客户 端 与 服务 器 端 建立 通信 ， 而 Docker 的 后 端 是 一 个 松 耦 


原 码 总 量 并 不 多 ， 而 


他 大 型 分 布 式 系统 那样 复杂 。Docker 的 ; 
Docker 对 用 户 而 言 是 一 个 简 


的 C/S 架 构 ， 


1.2 ”Docker 总 架构 图 


作为 Linux 平 台 上 的 一 种 容器 的 管理 引擎 ，Docker 并 不 像 
、Docker 架 构 的 设计 原理 等 。 


过 程 并 不 枯燥 ,我 们 可 以 从 中 学 到 很 多 东西 ， 如 Go 语言 的 运 
有 机 组 合 ， 支 撑 着 Docker 运 行 。 


， 架 构 中 的 模块 各 司 其 职 、 
1-1 所 示 。 架 构 中 主要 的 模块 有 : DockerClient、DockerDaemon、Docker Registry、Graph、Driver、libcontainer 以 及 Docker Container, 
户 通过 Docker Client 发 起 容器 的 管理 请 求 ， 请 求 最 终 发 往 Docker Daemon。 


合 的 架构 


er 的 总 架构 如 医 
户 而 言 ，Docker Client 是 与 Docker Daemon 建 立 通信 的 最 佳 途径 。| 


Doc 


对 


Docker Daemon 作 为 Docker 架 构 中 的 主体 部 分 ， 首 先 具备 服务 端的 功能 ， 有 能 力 接 收 Docker Client 发 起 的 请 求 ， 其 次 具备 Docker Client 请 求 的 处 理 能 力 。Docker Daemon 内 部 所 有 的 任务 均 
Engine 来 完成 ， 且 每 一 项 工作 都 以 一 个 Job 的 形式 存在 。 


Docker Daemon 需 要 完成 的 任务 很 多 ， 因 此 Job 的 种 类 也 很 多 。 若 用 户 需要 下 载 容器 镜像 ，Docker Daemon 则 会 创建 一 个 名 为 “pull” 的 Job， 运 行 时 从 Docker Registry 中 下 载 镜像 ， 并 通过 镜像 


m 

E 
理 驱动 graphdriver 将 下 载 的 镜像 存储 在 graph 中 ; 若 用 户 需要 为 Docker 容 器 创建 网 络 环境 ，Docker Daemon 则 会 创建 一 个 名 “allocate interface" 的 Job， 通 过 网 络 驱动 networkdriver 分 配 网 络 接口 的 
资源 .…… 


libcontainer 是 一 套 独立 的 容器 管理 解决 方案 ， 这 套 解 决 方案 涉及 了 大 量 Linux 内 核 方 盏 
完整 、 明 确 的 接口 给 Docker Daemon。 


的 特性 ， 如 : namespaces、cgroups 以 及 capabilities 等 。libcontainer 很 好 地 抽象 了 Linux 的 内 核 特性 ， 并 提供 


当 用 户 执 行 运行 容器 这 个 命令 之 后 ， 一 个 Docker 容 器 就 处 于 运行 状态 ， 该 容器 拥有 隔离 的 运行 环境 、 独 立 的 网 络 栈 资源 以 及 受 限 的 资源 等 。 


Docker Client 


Docker 


Daemon 


Docker 
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Repository 
(images? | 


Docker container 


rootfs (lavered? 


图 1-1 Docker 总 架构 图 


1.3 ”Docker 各 模块 功能 与 实现 分 析 


RI 


下 面 我 们 将 从 Docker 的 总 架构 图 入 手 ， 抽 离 出 架构 内 的 各 个 模块 ， 并 对 各 个 模块 进行 更 为 细 化 的 架构 分 析 与 功能 阐述 。 


14 ”Docker 运 行 案例 分 析 


1.3 节 着 重 介绍 了 Docker 架 构 中 各 个 模块 的 功能 ， 学 完 后 我 们 可 以 对 Docker 的 架构 有 一 个 宏观 的 认识 。 熟 悉 一 款 软件 ， 研 究 一 个 系统 ， 从 静态 的 角度 认识 架构 的 各 个 模块 ， 仅 仅 是 第 一 步 ， 从 动态 的 角 
度 ， 掌 握 软件 或 者 系统 的 运行 原理 ， 即 熟知 架构 中 模块 间 的 通信 逻辑 ， 无 疑 会 让 自己 对 软件 或 系统 的 理解 更 上 一 层 楼 。 本 节 将 从 实际 的 Docker 运 行 案例 出 发 ， 串 联 Docker 各 模块 ， 从 而 学 习 Docker 的 运行 
流程 。 分 析 原 型 为 Docker 中 的 docker pull&docker run 两 个 命令 。 


本 章 从 Docker 1.2.0 的 源码 入 手 ， 首 先 分 析 抽象 出 Docker 的 架构 图 ， 并 对 该 架构 图 中 的 各 个 模块 进行 功能 与 实现 的 简要 分 析 ， 最 后 通过 Docker 的 两 个 基础 命令 展示 了 Docker 内 部 的 运行 。 


通过 对 Docker 架 构 的 学 习 ， 可 以 全 面 深化 对 Docker 设 计 、 功 能 与 价值 的 理解 。 同 时 在 借助 Docker 实 现 用 户 定制 的 分 布 式 系统 时 ， 也 能 更 好 地 找到 已 有 平台 与 Docker 较 为 理想 的 契合 点 。 另 外 ， 熟 悉 
Docker 现 有 架构 以 及 设计 思想 ， 也 能 为 云 计算 PaaSs 和 领域 带 来 更 多 的 启示 ， 催 生出 更 多 创新 想法 。 


$622: Docker Client 创 建 与 命令 执行 


2.1 引言 


如 今 ， 作 为 业界 领先 的 轻 量 级 虚拟 化 容器 管理 引擎 ，Docker 给 全 球 开发 者 提供 了 一 种 新 颖 、 便 捷 的 软件 集成 测试 与 部 署 之 道 。 团 队 开 发 软件 时 ，Docker 可 以 提供 可 复 用 的 运行 环境 、 灵 活 的 资源 配 
置 、 便 捷 的 集成 测试 方法 ， 以 及 一 键 式 的 部 署 方式 。 可 以 说 ，Docker 在 简化 持续 集成 、 运 维 部 署 方面 将 其 功能 发 挥 得 淋漓 尽 致 ， 它 让 开发 者 从 重复 的 持续 集成 、 运 维 部 署 中 完全 解放 出 来 ， 把 精力 真正 地 倾 


注 在 开发 上 。 


然而 ， 要 把 Docker 的 功能 发 挥 到 极致 ， 并 非 一 件 易 事 。 在 深刻 理解 Docker 架 构 的 情况 下 ， 熟 练 掌握 Docker Client 的 使 用 也 非常 有 必要 。 前 者 可 以 参阅 第 1 章 ， 本 章 主要 针对 后 者 ， 从 源码 的 角度 分 析 
Docker Client， 力 求 帮助 开发 者 更 深刻 地 理解 Docker Client 的 具体 实现 ， 最 终 更 好 地 掌握 Docker Client 的 使 用 方法 。 


本 章 基于 Docker 1.2.0 的 源码 ， 分 析 Docker Client 的 内 容 。 主 要 包括 两 个 部 分 ， 分 别 是 DockerClient 的 创建 与 Docker Client 对 命令 的 执行 。 两 部 分 分 析 的 具体 内 容 如 下 。 


第 一 部 分 分 析 Docker Client 的 创建 。 这 部 分 的 分 析 可 分 为 以 下 三 个 步骤 : 

:分析 如 何 通过 docker 命 令 ， 解 析出 命令 行 Hag 参 数 ， 以 及 docker 命 令 中 的 请 求 参数 。 
© 分 析 如 何 处 理 具体 的 flag 参 数 信息 ， 并 收集 Docker Client 所 需 的 配置 信息 。 

:分析 如 何 创建 一 个 Docker Clients 


第 二 部 分 在 已 有 Docker Client 的 基础 上 ， 分 析 如何 执 行 docker 命 令 。 这 部 分 的 分 析 又 可 分 为 以 下 两 个 步骤 。 


- 分 析 如 何 解 析 docker 命 令 中 的 请 求 参数 ， 获 取 相 应 请 求 的 类 型 。 


' 分 析 Docker Client 如 何 执行 具体 的 请 求 命 令 ， 最 终 将 请 求 发 送 至 Docker Servers 
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如 今 ， 作 为 业界 领先 的 轻 量 级 虚拟 化 容器 管理 引擎 ，Docker 给 全 球 开发 者 提供 了 一 种 新 颖 、 便 捷 的 软件 集成 测试 与 部 署 之 道 。 团 队 开 发 软件 时 ，Docker 可 以 提供 可 复 用 的 运行 环境 、 灵 活 的 资源 配 
置 、 便 捷 的 集成 测试 方法 ， 以 及 一 键 式 的 部 署 方式 。 可 以 说 ，Docker 在 简化 持续 集成 、 运 维 部 署 方面 将 其 功能 发 挥 得 淋漓 尽 致 ， 它 让 开发 者 从 重复 的 持续 集成 、 运 维 部 署 中 完全 解放 出 来 ， 把 精力 真正 地 倾 


注 在 开发 上 。 


然而 ， 要 把 Docker 的 功能 发 挥 到 极致， 并 非 一 件 易 事 。 在 深刻 理解 Docker 架 构 的 情况 下 ， 熟 练 掌握 Docker Client 的 使 用 也 非常 有 必要 。 前 者 可 以 参阅 第 1 章 ， 本 章 主要 针对 后 者 ， 从 源码 的 角度 分 析 
Docker Client， 力 求 帮助 开发 者 更 深刻 地 理解 Docker Client 的 具体 实现 ， 最 终 更 好 地 掌握 Docker Client 的 使 用 方法 。 


本 章 基于 Docker 1.2.0 的 源码 ， 分 析 Docker Client 的 内 容 。 主 要 包括 两 个 部 分 ,分 别 是 DockerClient 的 创建 与 Docker Client 对 命令 的 执行 。 两 部 分 分 析 的 具体 内 容 如 下 。 


第 一 部 分 分 析 Docker Client 的 创建 。 这 部 分 的 分 析 可 分 为 以 下 三 个 步 又: 


“ 分 析 如 何 通 过 docker 命 令 ， 解 析出 命令 行 flag 参 数 ， 以 及 docker 命 令 中 的 请 求 参数 。 


“ 分 析 如 何 处 理 具 体 的 flag 参 数 信 息 ， 并 收集 Docker Client 所 需 的 配置 信息 。 


- 分 析 如 何 创 建 一 个 Docketr Client。 
第 二 部 分 在 已 有 Docker Client 的 基础 上 ， 分 析 如 何 执行 docker 命 令 。 这 部 分 的 分 析 又 可 分 为 以 下 两 个 步骤 。 
“ 分 析 如何 解 析 docker 命 令 中 的 请 求 参数 ， 获 取 相 应 请 求 的 类 型 。 


' 分 析 Docker Client 如 何 执行 具体 的 请 求 命令 ， 最 终 将 请 求 发 送 至 Docker Servere 


2.2 创建 Docker Client 


对 于 Docker 这 样 一 个 Client/Server 的 架构 ， 客 户 端的 存在 意味 着 Docker 相 应 任务 的 发 起 。 用 户 首先 需要 创建 一 个 DockerClient， 随 后 将 特定 的 请 求 类 型 与 参数 传递 至 Docker Client， 最 终 由 Docker 
Client 转 义 成 Docker Server 能 识别 的 形式 ， 并 发 送 至 Docker Server, 


Docker Client 的 创建 实质 上 是 Docker 用 户 通 过 二 进 制 可 执行 文件 docker， 创 建 与 Docker Server 建 立 联系 的 客户 端 。 以 下 分 3 个 小 节 分 别 阐述 Docker Client 的 创建 流程 。 


Docker Client 完 整 的 运行 流程 如 图 2-1 所 示 。 
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图 2-1 DockerClient 的 运行 流程 


通过 学 习 图 2-1， 我 们 可 以 更 为 清晰 地 了 解 Docker Client 创 建 及 执行 请 求 的 过 程 。 其 中 涉及 诸多 Docker 源 码 层次 中 的 专 有 和 名词， 本 章 后 续 会 一 一 解释 与 分 析 。 


23 ”Docker 命 令 执 行 


main 函 数 执行 到 这 个 阶段 ， 有 以 下 内 容 需 要 为 Docker 命 令 的 执行 服务 : 创建 完毕 的 Docker Client，docker 命 令 中 的 请 求 参数 (经 flag 解 析 后 存放 于 flag.Arg () ) 。 也 就 是 说 ， 程 序 需要 使 用 Docker 
Client 来 分 析 Docker 命 令 中 的 请 求 参数 ， 得 出 请 求 的 类 型 ， 转 义 为 Docker Server 可 以 识别 的 请 求 之 后 ， 最 终 发 送 给 Docker Server, 


Docker Client 主 要 完成 两 方面 的 工作 : 解析 请 求 命 令 ， 得 出 请 求 类 型 ; 执行 具体 类 型 的 请 求 。 本 节 将 从 这 两 个 方面 深入 分 析 Docker Client。 


本 章 从 源码 的 角度 分 析 了 如 何 通 过 docker 可 执行 文件 创建 Docker Client， 最 终 发 送 用 户 请 求 至 Docker Server, 


通过 学 习 与 理解 Docker Client 相 关 的 源码 实现 ， 不 仅 可 以 让 用 户 熟练 掌握 Docker 命 令 的 使 用 ， 还 可 以 使 用 户 在 特殊 情况 下 有 能 力 修改 Docker Client 的 源码 ， 使 其 满足 自身 系统 的 某 些 特殊 需求 ， 以 达 
到 定制 Docker Client 的 目的 ， 最 大 限度 地 发 挥 Docker 开 源 思 想 的 价值 。 
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31 引言 


自 Docker 诞 生 以 来 ， 便 引领 了 轻 量 级 虚拟 化 容器 领域 的 技术 热潮 。 在 这 一 潮流 下 ，Google、IBM、Redhat 等 业界 普 楚 纷纷 加 入 Docker 阵 营 。 虽 然 目前 Docker 仍 主要 基于 Linux 平 台 ， 但 是 Microsoft 
却 多 次 宣布 对 Docker 的 支持 ， 从 先前 宣布 的 Azure 支 持 Docker 与 Kubernetes， 到 如 今 宣布 的 下 一 代 Windows Server 原 生态 支持 Docker。Microsoft 的 这 一 系列 举措 多 少 喻 示 着 向 Linux 世 界 的 妥协 ， 当 然 
这 也 不 得 不 让 世人 对 Docker 的 巨大 影响 力 有 重新 的 认识 。 


Docker 的 影响 力 不 言 而 喻 ， 但 如 果 需 要 深入 学 习 Docker 的 内 部 实现 ， 最 重要 的 就 是 理解 Docker Daemon。 在 Docker 架 构 中 ，Docker Client 通 过 特定 的 协议 与 Docker Daemon 进 行 通 信 ， 而 Docker 
Daemon 主 要 承载 了 Docker 运 行 过 程 中 的 大 部 分 工作 。 


Docker Daemon 是 Docker 架 构 中 运行 在 后 台 的 守护 进程 ， 大 致 可 以 分 为 Docker Server、Engine 和 Job 三 部 分 。 三 者 的 关系 大 致 如 下 : Docker Daemon 通 过 Docker Server 模 块 接收 Docker Client 的 
请 求 ， 并 在 Engine 中 处 理 请 求 ， 然 后 根据 请 求 类 型 ， 创 建 出 指定 的 Job 并 运行 。 由 于 用 户 的 请 求 不 同 ，DockerDaemon 会 创建 不 同 的 Job 来 完成 任务 ， 如 : 用 户 发 起 镜像 下 载 请 求 ，DockerDaemon 创 建 名 
73 "pull" 的 Job; 用 户 发 起 启动 容器 的 请 求 ，DockerDaemon 创 建 名 为 “start” 的 Job.……… 


Docker Daemon 的 架构 如 图 3-1 所 示 。 


本 章 从 源码 的 角度 ， 主 要 分 析 Docker Daemon 的 启动 流程 。 由 于 Docker Daemon 和 Docker Client 的 启动 流程 有 很 多 的 相似 之 处 ， 故 本 章 不 再 歼 述 Docker Daemon 启 动 的 前 期 工作 、flag 人 参数 的 解析 
等 内 容 ， 着 重 分 析 Docker Daemon 启 动 流程 中 最 为 重要 的 环节 : 创建 Daemon 过 程 中 mainDaemon () 的 实现 。 
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图 3-1 DockerDaemon 架 构 示意 图 
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Docker Daemon 的 架构 如 图 3-1 所 示 。 
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图 3-1 DockerDaemon 架 构 示意 图 


3.2 Docker Daemon 的 启动 流程 


Docker Daemon 和 Docker Client 的 启动 均 通过 可 执行 文件 docker 完 成 ， 因 此 两 者 的 启动 流程 非常 相似 。Docker 可 执行 文件 运行 时 ， 程 序 运行 通过 不 同 的 命 


各 自 相应 的 部 分 。 


execdriver 


令 行 flag 参 数 ， 区 分 两 者 ， 并 最 终 运行 两 者 


启动 Docker Daemon 时 ， 一 般 可 以 使 用 以 下 命令 : docker--daemon=true、docker-d; docker-d=true 等 。 随 后 由 Docker 的 main () 函数 来 解析 以 上 命令 的 相应 flag 参 数 ， 并 最 终 完成 Docker 


Daemon 的 启动 。 


首先 ， 附 上 Docker Daemon 的 启动 流程 图 ， 如 图 3-2 所 示 。 


flag. Parse() 


showVersion() 


*flDebug 


los, Setenv( "Debug" , 1) 


flHost 
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mnainDaemon () 


图 3-2 ”DockerDaemon 启 动 流程 图 


本 书 第 2 章 已 经 描述 了 Docker 中 main () 函数 运行 的 很 多 前 期 工作 ，Docker Daemon 的 启动 也 会 涉及 这 些 工作 ， 故 在 此 略 去 相同 部 分 ， 主 要 针对 后 续 仅 和 Docker Daemon 相 关 的 内 容 进行 深入 分 
析 ， 即 mainDaemon () 的 具体 源码 实现 。 


3.3 mainDaemon () 的 具体 实现 


Docker Daemon 的 启动 流程 图 展示 了 DockerDaemon 的 从 无 到 有 。 通 过 分 析 流 程 图 ， 我 们 可 以 得 出 一 个 这 样 的 结论 : 区 分 Docker Daemon 与 Docker Client 的 关键 在 于 flag 参 数 fIDaemon 的 值 。 一 
旦 *flIDaemon 的 值 为 真 ， 则 代表 docker 二 进 制 需 要 启动 的 是 Docker Daemon。 有 关 Docker Daemon 的 所 有 的 工作 ， 都 被 包含 在 函数 mainDaemon () 的 具体 实现 中 。 


宏观 来 讲 ，mainDaemon () 的 使 命 是 : 创建 一 个 守护 进程 ， 并 保证 其 正常 运行 。 


从 功能 的 角度 来 说 ，mainDaemon () 实现 了 两 部 分 内 容 : 第 一 ， 创 建 Docker 运 行 环境 ; 第 二 ， 服 务 于 Docker Client， 接 收 并 处 理 相应 请 求 (Docker Server 的 初始 化 ) 。 


从 实现 细节 来 分 析 ，mainDaemon () 的 实现 流程 主要 包含 以 下 步骤 : 


1) daemon 的 配置 初始 化 。 这 部 分 在 init () 函数 中 实现 ， 即 在 mainDaemon () 运行 前 就 执行 ， 但 由 于 这 部 分 内 容 和 mainDaemon () 的 运行 息息相关 ， 可 以 认为 是 mainDaemon () 运行 的 先决 
条 件 。 


2) 命令 行 flag 参 数 检查 。 
3) 创建 engine 对 象 。 
4) 设置 engine 的 信号 捕获 及 处 理 方法 。 


5) 加 载 builtins。 


6) 使 用 goroutine 加 载 daemon 对 象 并 运行 。 


7) 打印 Docker 版 本 及 驱动 信息 。 


8) serveapi 的 创建 与 运行 。 


对 于 以 上 内 容 ， 本 章 将 一 一 深入 分 析 。 


3.4 总 结 


本 章 从 源码 的 角度 分 析 了 Docker Daemon 的 启动 ， 着 重 分 析 了 mainDaemon () 的 实现 。 


Docker Daemon 作 为 Docker 架 构 中 的 主干 部 分 ， 负 责 了 Docker 内 部 几乎 所 有 操作 的 管理 。 学 习 Docker Daemon 的 具体 实现 ， 可 以 对 Docker 架 构 有 一 个 较为 全 面 的 认识 。 总 结 而 言 ，Docker 的 运行 
载体 为 Daemon， 调 度 管理 由 Engine 负 责 ， 任 务 执行 靠 Job。 
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41 引言 


Docker 的 生态 系统 日 趋 完善 ， 开 发 者 群体 也 在 日 趋 庞大 ， 这 些 现象 都 使 得 工业 界 对 Docker 持 续 抱 有 乐观 的 态度 。 如 今 ， 对 于 广大 开发 者 而 言 ， 使 用 Docker 已 然 不 是 门槛 ， 享 受 Docker 带 来 的 福利 也 不 
再 困难 。 然 而 ， 如 何 探寻 Docker 适 应 的 场景 ， 如 何 发 展 Docker 周 边 的 技术 ， 以 及 如 何 弥合 Docker 新 技术 与 传统 物理 机 或 虚拟 机 技术 之 间 的 鸿沟 ， 已 经 成 为 Docker 研 究 者 们 要 思考 与 解决 的 问题 。 


在 Docker 架 构 中 Docker Daemon 支 撑 着 整个 后 台 进 程 的 运行 ， 同 时 也 统一 化 管理 着 Docker 架 构 中 graph、graphdriver、execdriver、volumes、Docke 容 器 等 众多 资源 。 可 以 说 ，Docker Daemon 
复杂 的 运作 均 由 daemon 对 象 来 调度 ， 而 NewDaemon 的 实现 恰巧 可 以 帮助 大 家 了 解 这 一 切 的 来 龙 去 脉 。 通过 本 章 内 容 的 介绍 ， 我 们 力求 帮助 广大 Docker 爱 好 者 更 多 地 理解 Docker 的 核心 一 一 Docker 
Daemon 的 实现 。 


本 章 从 源码 角度 ， 分 析 Docker Daemon 加 载 过 程 中 NewDaemon 的 实现 ， 整 个 分 析 过 程 如 图 4-1 所 示 。 


由 图 4-1 可 见 ，Docker Daemon 中 NewDaemon 的 执行 流程 主要 包含 12 个 独立 的 步骤 : 处 理 配 置信 息 、 检 测 系统 支持 及 用 户 权 限 、 配 置 工作 路 径 、 加 载 并 配置 graphdriver、 创 建 Docker Daemon 网 
络 环 境 、 创 建 并 初始 化 graphdb、 创 建 execdriver、 创 建 daemon 实 例 、 检 测 DNS 配 置 、 加 载 已 肥 容 器、 设置 shutdown 处 理 方法 ， 以 及 返回 daemon 实 例 。 


下 面 我 们 将 在 NewDaemon 的 具体 实现 中 ， 详 细 分 析 以 上 内 容 。 
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图 4-1 Docker Daemon 中 NewDaemon 执 行 流程 图 
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发 者 而 言 ， 使 用 Docker 已 然 不 是 门槛 ， 享 受 Docker 带 来 的 福利 也 不 
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本 章 从 源码 角度 ， 分 析 Docker Daemon 加 载 过 程 中 NewDaemon 的 实现 ， 整 个 分 析 过 程 如 图 4-1 所 示 。 
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图 4-1 Docker Daemon 中 NewDaemon 执 行 流程 图 


4.2 NewDaemon 有 具体 实现 


本 书 第 3 章 对 于 Docker Daemon 启 动 的 分 析 过 程 ， 有 这 样 一 个 环节 : 使 用 协 程 加 载 daemon 对 象 。 在 加 载 并 运行 daemon 对 象 时 ， 所 做 的 第 一 个 工作 是 : 


d, err := daemon.NewDaemon (daemonCfg, eng) 


简单 分 析 一 下 这 行 代码 。 
- 函数 名 : NewDaemon 
' 调用 此 函数 的 包 名 : daemon 


' 范 数 具体 实现 源 文件 : ./docker/docker/daemon/daemon. go 


“ BHARA: daemonCfg， 定 义 Docker Daemon 运 行 过 程 中 所 需 的 众多 配置 信息 ; eng， 在 mainDaemon 中 创建 的 Engine 对 象 实例 


“ 函数 返回 内 容 : d， 具 体 的 Daemon 对 象 实例 ; err， 错 误 状 态 


进入 ./docker/docker/daemon/daemon.go 中 ， 寻 找 函 数 NewDaemon 的 具体 实现 ， 源 码 如 下 : 


func NewDaemon (config *Config, eng *engine.Engine) (*Daemon, error) { 


daemon, err := NewDaemonFromDirectory (config, eng) 
if err !- nil ( 
return nil, err 


return daemon, nil 


可 见 ， 在 实现 NewDaemon 的 过 程 中 ， 要 通过 NewDaemonFromDirectory 函 数 来 实现 创建 Daemon 的 运行 环境 。 该 函数 的 实现 ， 传 入 参数 以 及 返回 类 型 与 NewDaemon 函 数 完全 相同 。 接 下 来 将 详细 


分 析 NewDaemonFromDirectory 的 实现 细节 。 


43 ”应 用 配置 信息 


NewDaemonFromDirectory 的 实现 过 程 中 ， 第 一 个 工作 是 : f 


0 何 应 用 传 入 的 配置 信息 。 这 部 分 配置 信息 服务 于 Docker Daemon 的 运行 ， 并 在 Docker Daemon 启 动 初期 初始 化 完毕 。 配 置信 息 的 主要 


功能 是 : 供用 户 自由 配置 Docker 的 可 选 功 能 ， 使 得 Docker 的 运行 更 贴近 用 户 期 待 的 运行 场景 。 


配置 信息 的 处 理 包含 4 部 分 : 
- 配置 Docker 容 器 的 MTU 

“ 检测 网 桥 配 置信 息 

“ 查验 容器 间 的 通信 配置 
` 处 理 PID 文 件 配置 


下 面 逐 一 分 析 配 置信 息 的 处 理 。 


4.4 检测 系统 支持 及 用 户 权限 


初步 处 理 完 Docker 的 配置 信息 之 后 ，Docker 立 即 对 自身 的 运行 环境 进行 一 系列 的 检测 。 检 测 主 要 包括 以 下 三 方面 : 


“ 操作 系统 类 型 对 Docker Daemon 的 支持 ; 


“ 用 户 权 限 的 级 别 ; 


“内核 版 本 与 处 理 器 的 支持 。 


系统 支持 与 用 户 权限 检测 的 实现 较为 简单 ， 源 码 实现 如 下 : 


if runtime.GOOS !- "linux" ( 

log.Fatalf("The Docker daemon is only supported on 
} 
if os.Geteuid() != 0 ( 


linux") 


log.Fatalf("The Docker daemon needs to be run as root") 


} 

if err := checkKernelAndArch(); err != nil { 
log.Fatalf (err.Error()) 

i 


首先 ， 通 过 runtime.GOOS 检 测 操作 系统 的 类 型 。runtime.GOOS 返 回 运行 程序 所 在 操作 系统 的 类 型 ， 可 以 是 Linux、Darwin、FreeBSD 等 。 结 合 具体 代码 ， 可 以 发 现 ， 若 操作 系统 不 为 Linux， 将 报 出 
Fatal 错 误 日 志 ， 内 容 为 “Docker Daemon 只 能 支持 Linux 操 作 系统 ”。 


接着 ， 通 过 os.Geteuid () ， 检 测 程序 用 户 是 否 拥有 足够 权限 。 
出 Fatal 错 误 日 志 。 


最 后 ， 通 过 checkKernelAndArch () ， 检 测 内 核 的 版 本 以 及 3 


os.Geteuid () 返回 调用 者 所 在 组 的 组 id。 结 合 具 体 源码 分 析 可 知 ， 若 返回 不 为 0， 则 说 明 docker 程 序 不 是 以 root 用 户 的 身份 运行 ， 报 


上 机 处 理 器 类 型 。checkKernel-AndArch () 的 实现 同样 位 于 ./docker/docker/daemon/daemon.go#L1097-L1119。 实 现 过 程 中 ， 第 一 


个 工作 是 : 检测 程序 运行 所 在 的 处 理 器 架构 是 否 为 “amd64”,， 而 
的 内 核 版 本 若 过 低 ， 则 很 有 可 能 出 现 不 稳定 的 状况 ， 因 此 Docker 官 


前 Docker 运 行 时 只 能 支持 amd64 的 处 理 器 架构 。 第 二 个 工作 是 : 检测 Linux 内 核 版 本 是 否 满足 要 求 ， 而 目前 Docker Daemon 运 行 所 需 
方 建议 用 户 升级 内 核 版 本 至 3.8.0 或 以 上 版 本 (包括 3.8.0) 。 


45 配置 工作 路 径 


配置 Docker Daemon 的 工作 路 径 ， 主 要 是 创建 Docker Daemon 运 行 中 所 在 的 工作 目录 。 实 现 过 程 中 ， 通 过 config 中 的 Root 属性 来 完成 。Docker Daemon 的 root 目 录 作 用 非常 大 ， 几 乎 涵盖 Docker 
在 宿主 机 上 运行 的 所 有 信息 ， 包 括 : 所 有 的 Docker 镜 像 内 容 、 所 有 Docker 容 器 的 文件 系统 、 所 有 Docker 容 器 的 元 数据 、 所 有 容器 的 数据 卷 内 容 等 。 


在 默认 配置 文件 中 ，Root 属 性 的 值 为 ”/var/lib/docker”。 


在 配置 工作 路 径 的 代码 实现 中 ， 步 又 如 下 : 


1) 使 用 规范 路 径 创建 一 个 TempDir， 路 径 名 为 tmp。 
2) 通过 tmp,， 创建 一 个 指向 tmp 的 文件 符号 连接 realTmp。 
3) 使 用 realTemp 的 值 ， 创 建 并 赋值 给 环境 变量 TMPDIR。 


4) 处 理 config 的 属性 EnableSelinuxSupport。 


5) 将 realRoot 重 新 赋值 于 config.Root， 并 创建 Docker Daemon 的 工作 根 目录 。 


46 ”加 载 并 配置 graphdriver 


加 载 并 配置 存储 驱动 graphdriver， 目 的 在 于 : 使 得 Docker Daemon 创 建 Docker 镜 像 管理 所 需 的 驱动 环境 。graphdriver 用 于 完成 Docker 镜 像 的 管理 ， 包 括 获取 、 存 储 以 及 容器 rootfs 的 构建 等 。 


4.7 配置 Docker Daemon 网 络 环境 


创建 Docker Daemon 运 行 环境 的 时 候 ， 配 置 Docker 所 在 宿主 机 的 网 络 环境 是 极为 重要 的 一 个 环节 。 这 不 仅 关系 着 将 来 容器 对 外 的 通信 ， 同 样 也 关系 着 容器 间 的 通信 。 


配置 Docker 宿 主机 的 网 络 环境 时 ，Docker Daemon 通 过 运行 名 为 init_networkdriver 的 Job 来 完成 。 源 码 实 现 如 下 : 


if !config.DisableNetwork ( 


job 


job. 
job. 
job. 
job. 
job. 
job. 


:= eng.Job("init networkdriver") 

SetenvBool ("EnableIptables", config.EnableIptables) 

SetenvBool ("InterContainerCommunication", config.InterContainerCommunication) 
SetenvBool ("EnableIpForward", config.EnableIpForward) 

Setenv ("Bridgelface", config.Bridgelface) 

Setenv("BridgeIP", config.BridgeIP) 

Setenv("DefaultBindingIP", config.DefaultlIp.String()) 


if err := job.Run(); err !- nil ( 


) 


return nil, err 


分 析 以 上 源码 可 知 ， 通 过 config 中 的 DisableNetwork 属 性 来 判断 是 否 执行 Job。 在 默认 配置 文件 中 ， 该 属性 曾 被 定义 ， 却 没有 初始 值 ， 然 而 在 应 用 配置 信息 这 个 步骤 (4.335) ，Docker 处 理 网 络 功能 
配置 时 ， 将 DisableNetwork 属 性 赋值 为 false。 故 以 上 判断 语句 结果 为 true， 执 行 相应 的 代码 块 。 


配置 DockerDaemon 网 络 环境 的 工作 主要 通过 init_networkdriver 这 个 Job 来 完成 。Docker 首 先 创建 名 为 init_networkdriver 的 Job， 随 后 为 此 Job 设 置 环境 变量 ， 环 境 变量 的 值 如 下 : 


©- 环境 变量 EnableIptables， 使 用 configEnableIptables 来 赋值 ， 默 认 值 为 true。 


* 环境 变 


量 InterContainerCommunication， 使 用 config InterContainerCommunication 来 赋值 ， 为 默认 值 true。 


: 环境 变量 EnableIpForward， 使 用 configEnableIpForward 来 赋值 ， 默 认 值 为 true。 


* 环境 变 


量 Bridgelface， 使 用 config.Bridgelface 来 赋值 ， 为 空 字符 串 ""。 


: 环境 变量 BridgeIP， 使 用 config BridgeIP 来 赋值 ， 为 空 字符 串 ""。 


* 环境 变 


量 DefaultBindingIP， 使 用 config.DefaultIp.String () 来 赋值 ， 上 默认 值 为 "0.0.0.0"。 


设置 完 环境 变量 之 后 ，Docker 随 即 运行 此 Job， 由 于 在 eng 中 key 为 init_networkdriver 的 handler，value 为 bridge.InitDriver 函 数 ， 故 执行 bridge.InitDriver 函 数 ， 具 体 的 实现 位 


7F./docker/docker/daemon/networkdriver/bridge/dirver.go, FAJ: 


- 获取 为 Docker 容 器 服务 的 网 络 接口 JP 地 址 。 


: 创建 指 


定 IP 地 址 的 网 桥接 口 。 


“ 启用 Iptables 功 能 并 进行 配置 。 


“另外 ，Job 为 eng 实 例 注册 了 4 个 Handler，Handler 名 分 别 为 : allocate_interface、telease_interface、allocate_port 和 和 link。 


Docker Daemon 的 网 络 初始 化 关乎 Docker 容 器 的 通信 能 力 ， 是 Docker 架 构 中 最 为 基础 的 知识 之 一 。 第 6 章 将 为 大 家 分 析 Docker Daemon 网 络 环境 的 创建 。 


4.8 创建 graphdb 并 初始 化 


graphdb 是 一 个 构建 在 SQLite 之 上 的 图 形 数据 库 ， 通 常用 来 记录 节点 命名 以 及 节点 之 间 的 关联 。 在 Docker 的 世界 中 ， 用 户 可 以 通过 link 操 作 ， 使 得 Docker 容 器 之 间 建 立 一 种 关联 ， 而 Docker Daemon 
正 是 使 用 graphdb 来 记录 这 种 容器 间 的 关联 信息 。Docker 创 建 graphdb 的 源码 如 下 : 


graphdbPath := path.Join(config.Root, "linkgraph.db") 
graph, err :- graphdb.NewSqliteConn (graphdbPath) 
if err != nil ( 

return nil, err 


) 


以 上 代码 首先 确定 graphdb 的 目录 为 /var/lib/docker/linkgraph.db; 随后 通过 graphdb 包 内 的 NewSqliteConn 打 开 graphdb， 使 用 的 驱动 为 sqlite3， 数 据 源 的 名 称 
73/var/lib/docker/linkgraph.db; 最 后 通过 NewDatabase 函 数 初始 化 整个 graphdb， 为 graphdb 创 建 entity 表 和 edge 表 ， 并 在 这 两 个 表 中 初始 化 部 分 数据 。NewsqliteConn 函 数 的 实现 位 
于 ./docker/docker/pkg/graphdb/conn_sqlite3.go， 代 码 实现 如 下 : 


func NewSqliteConn(root string) (*Database, error) ( 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/15329/OEBPS/Text/... 
conn, err := sql.Open("sqlite3", root) i 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/15329/OEBPS/Text/... 
return NewDatabase (conn, initDatabase) T 


49 创建 execdriver 


execdriver 是 Docker 中 用 来 执行 Docker 容 器 任务 的 驱动 。 创 建 并 初始 化 graphdb 之 后 ，Docker Daemon 随 即 开始 创建 了 execdriver， 具 体 源 码 如 下 : 


ed, err := execdrivers.NewDriver(config.ExecDriver, config.Root, sysInitPath, sysInfo) 


分 析 以 上 源码 可 知 ，DockerDaemon 创 建 execdriver 时 ， 需 要 以 下 四 部 分 信息 。 


- config.ExecDriver: Docker 运 行 时 中 用 户 指定 使 用 的 execdriver 类 型 ， 在 默认 配置 文件 中 值 为 native。 用 户 也 可 以 在 启动 DockerDaemon 将 这 个 值 配 置 为 Ix¢， 则 导致 Docker 使 用 lxc 类 型 的 驱动 执行 Docker 容 
器 的 内 部 操作 。 


- config.Root: Docker 运 行 时 的 root 路 径 ， 默 认 配 置 文件 中 为 /var/lib/docker。 
“sysInitPath: 系统 中 存放 dockerinit 二 进 制 文件 的 路 径 ， 一 般 为 /var/lib/docker/init/dockerinit-1.2.0。 
“sysInfo; 系统 功能 信息 ， 包 括 : 容器 的 内 存 限制 功能 ， 交 换 区 内 存 限制 功能 ， 数 据 转发 功能 ， 以 及 AppArmotr 安 全 功能 等 。 


在 执行 execdrivers.NewDriver 之 前 ， 首 先 通 过 以 下 代码 ， 获 取 期 望 的 目标 dockerinit 文 件 的 路 径 localPath， 以 及 系统 中 dockerinit 文 件 实际 所 在 的 路 径 syslnitPath : 


localCopy := path.Join(config.Root, "init", fmt.Sprintf("dockerinit-$s", dockerversion.VERSION)) 
sysInitPath := utils.DockerInitPath (localCopy) 


通过 执行 以 上 代码 ，localCopy 为 /var/lib/docker/init/dockerinit-1.2.0， 而 sysylnitPath 为 当前 Docker 运 行 时 中 dockerinit-1.2.0 实 际 所 处 的 路 径 ，utils.DockerlnitPath 实 现 位 
于 ./docker/docker/utils/util.go。 若 localCopy 与 sysylnitPath 不 相等 ， 则 说 明 当 前 系统 中 的 dockerinit 二 进 制 文件 ， 不 在 localCopy 路 径 下 ， 则 需要 将 其 复制 至 localCopy 下 ， 并 对 该 文件 设 定 权 限 。 


设 定 完 dockerinit 二 进 制 文件 的 位 置 之 后 ，Docker Daemon 创 建 sysinfo 对 象 ， 记 录 系统 的 功能 属性 。Syslnfo 的 定义 位 于 ./docker/docker/pkg/sysinfo/sysinfo.go， 如 下 所 示 : 


type SysInfo struct { 


MemoryLimit bool 
SwapLimit bool 
IPv4ForwardingDisabled bool 
AppArmor bool 


其 中 Docker Daemon 通 过 判断 cgroups 文 件 系统 挂 载 路 径 下 是 否 均 存 在 memory.limit in_bytes 和 memory.soft_limit_in_bytes 文 件 来 为 MemoryLimit 赋 值 ， 若 均 存在 ， 则 置 为 true， 否 则 置 为 false; 
通过 判断 memory.memsw.limit in_bytes 文 件 是 否 存在 来 为 SwapLimit 赋 值 ， 若 该 文件 存在 ， 则 置 为 true， 否 则 置 为 false。AppArmor 的 值 则 是 通过 宿主 机 上 是 和 否 存在 /syskernelsecurityapparmor 来 
判断 ， 若 存在 ， 则 置 为 true， 否 则 置 为 false。 


执行 execdrivers.NewDriver 时 ， 返 回 execdriver.Driver 对 象 实例 ， 具 体 代码 实现 位 于 ./docker/docker/daemon/execdriver/execdrivers/execdrivers.go， 由 于 选择 使 用 native 作 为 exec 驱 动 ， 故 执行 


以 下 代码 ， 返 回 最 终 的 execdriver， 其 中 native.NewDriver 实 现 位 于 ./docker/docker/daemon/execdriver/native/driver.go: 


return native.NewDriver (path.Join (root, "execdriver", "native"), initPath) 


至 此 ， 一 个 execdriver 的 实例 ed 被 Docker 成 功 创建 。 


4.10 创建 daemon 实 例 


Docker Daemon 在 经 过 以 上 多 个 环节 的 设置 之 后 ， 整 合 众 多 已 经 创建 的 对 象 ， 创 建 最 终 的 Daemon 对 象 实例 daemon。Daemon 对 象 实 例 daemon 涉 及 的 内 容 极 多 ， 比 如 : 对 于 Docker 镜 像 的 存储 可 
以 通过 graph 来 管理 、 所 有 Docker 容 器 的 元 数据 信息 都 保存 在 containers 对 象 中 、 整 个 Docker Daemon 的 任务 执行 位 于 eng 属 性 中 ， 等 等 。 


创建 daemon 实 例 的 源码 实现 如 下 : 


daemon := &Daemon( 
repository: daemonRepo, 
containers: &contStore(s: make (map[string]*Container)], 
graph: —— gr 7. 
repositories: repositories, 
idIndex: truncindex.NewTruncIndex ([]stringí])), 
sysInfo: sysInfo, 
volumes: volumes, 


config: config, 


containerGraph: 
driver: 
sysInitPath: 
execDriver: 
eng: 


graph, 
driver, 
sysInitPath, 
ed, 

eng, 


分 析 Daemon 类 型 的 属性 如 表 4-1 所 示 。 


属性 名 


repository 


containers 


表 4-1 Daemon 类 型 属性 分 析 表 
作用 
存储 所 有 Docker 容器 信息 的 路 径 ， 默 认为 /var/lib/docker/containers 
用 于 存储 Docker 容器 信息 的 对 象 


属性 名 


graph 


repositories 


idIndex 
sysInfo 
volumes 
config 


containerGraph 


driver 


sysInitPath 


execDriver 


eng 


4.11 


检测 DNS 配置 


( 续 ) 
作用 


存储 Docker 镜像 的 graph 对 象 

存储 本 机 所 有 Docker 镜像 repo 信息 的 对 象 

用 于 通过 简短 有 效 的 字符 串 前 级 定位 唯一 的 镜像 

系统 功能 信息 

管理 宿主 机 上 volumes 内 容 的 graphdriver， 默 认为 v 类 型 
Config.go 文件 中 的 配置 信息 ， 以 及 执行 后 产生 的 配置 DisableNetwork 
存放 Docker 镜像 关系 的 graphdb 

管理 Docker 镜像 的 驱动 graphdriver， 默 认为 aufs 类 型 
系统 dockerinit 二 进 制 文件 所 在 的 路 径 

Docker Daemon 的 exec 驱动 ， 默 认为 native 类 型 

Docker 的 执行 引擎 Engine 类 型 


创建 完 Daemon 类 型 实例 daemon 之 后 ，Docker Daemon 使 用 daemon.checkLocaldns () 检测 Docker 运 行 环境 中 DNS 的 配置 ，checkLocaldns 函 数 的 定义 位 
于 ./docker/docker/daemon/daemon.go#L854-L856， 代 码 如 下 : 


func (daemon *Daemon) checkLocaldns () 


resolvConf, err := resolvconf.Get () 


if err != nil ( 
return err 


error { 


) 
if len(daemon.config.Dns) == 0 && utils.CheckLocalDns (resolvConf) ( 


log.Infof("Local (127.0.0.1) DNS resolver found in resolv.conf and containers can't use it. Using default external servers : 


daemon.config.Dns = DefaultDns 


return nil 


$v", DefaultDns) 


以 上 代码 首先 通过 resolvconf.Get () 方法 获取 宿主 机 /etc/resolv.conf 中 的 DNS 服务 器 信息 。 若 宿主 机 上 DNS 文件 resolv.conf 中 有 127.0.0.1， 而 Docker 容 器 在 自身 内 部 不 能 


外 在 DNS 服务 器 ， 为 8.8.8.8，8.8.4.4; 若 宿 3 该 地 址 。 最 终 Docker Daemon 将 DNS 服务 器 地 址 赋值 给 config 文 件 中 


的 Dns 属 性 。 


EF 机 上 的 resolv.conf 有 Docker 容 器 可 以 使 
户 通过 Docker Daemon 创 建 Docker 容 器 时 ， 若 不 指定 DNS 服 务 器 地 址 ， 则 Docker Daemon 将 会 使 


4.12 ”启动 时 加 载 已 有 Docker 容 器 


在 Docker Daemon 重 启 时 ， 很 有 可 能 之 前 有 遗留 的 Docker 容 器 。 对 于 这 部 分 容器 ，DockerDaemon 寻 
中 。 为 了 保证 重启 之 后 Docker 容 器 的 信息 不 丢失 ，DockerDaemon 首 先 会 进入 该 


维护 。 


的 DNS 服务 器 地 址 ， 则 Docker Daemon 采 上 
daemon.Config.Dns 作 为 容器 内 部 的 DNS 服务 器 地 址 。 


Docker Daemon 加 载 Docker 容 器 的 源码 实现 位 于 ./docker/docker/daemon/daemon.go#L854-L856， 如 下 : 


该 地 址 ， 故 采 


默认 


启 前 ， 一 直 将 元 数据 信息 存储 在 daemon.repository (目录 为 /var/lib/docker/containers) 
录 去 查看 ， 是 否 存 在 遗留 的 Docker 容 器 。 若 存在 ， 则 Docker Daemon 加 载 这 部 分 容器 ， 将 容器 信息 收集 ， 并 做 相应 的 


if err := daemon.restore(); 


return nil, err 


} 


err != nil { 


需要 注意 的 是 : 由 于 Docker Daemon 的 


启 不 会 


启 所 有 | 


内 存 中 的 容器 对 象 以 及 config.json 文 件 中 将 容器 主 进 程 的 PID 设 为 0。 


启 前 运行 的 容器 ， 故 Docker Daemon 加 载 已 有 容器 时 ， 会 判断 容器 之 前 的 状态 是 否 为 运行 ， 若 是 的 话 ， 会 将 该 容器 的 状态 置 为 退出 ， 并 在 


413 ”设置 shutdown 的 处 理 方法 


加 载 完 已 有 Docker 容 器 之 后 ，Docker Daemon 设 置 了 多 项 在 shutdown 操 作 中 需要 执行 的 处 理 方法 。 也 就 是 说 ， 当 Docker Daemon 接 收 到 特定 信号 ， 需 要 执行 shutdown 操 作 时 ， 先 执行 这 些 处 理 方 


法 完成 善后 工作 ， 最 终 再 实现 物理 意义 上 的 shutdown。 实 现 源码 如 下 : 


eng.OnShutdown(func() ( 


if err := daemon.shutdown(); err !- nil { 
log.Errorf ("daemon.shutdown(): $s", err) 

) 

if err := portallocator.ReleaseAll(); err !- nil ( 
log.Errorf ("portallocator.ReleaseAll(): $s", err) 

} 

if err := daemon.driver.Cleanup(); err != nil { 
log.Errorf ("daemon.driver.Cleanup(): $s", err.Error()) 

) 

if err := daemon.containerGraph.Close(); err != nil ( 
log.Errorf ("daemon.containerGraph.Close(): $s", err.Error()) 


) 


由 以 上 源码 可 见 ，eng 对 象 shutdown 操 作 执行 时 ， 需 要 执行 以 上 作为 参数 的 func () C... 
- 运行 daemon 对 和 象 的 shutdown 函 数 ， 做 daemon 方 面 的 善后 工作 。 

- 通过 portallocator.ReleaseAll () ， 释 放 所 有 之 前 占用 的 端口 资源 。 

* d ifdaemon.driver.Cleanup () ， 通 过 graphdriver 实 现 unmount 所 有 有 关 镜 像 layer 的 挂 载 点 。 


- 通过 daemon.containerGraph.Close () 关闭 graphdb 的 连接 。 


444 ”返回 daemon 对 象 实例 


当 所 有 的 工作 完成 之 后 ，Docker Daemon 返 回 daemon 实 例 ， 意 味 着 NewDaemon 函 数 执行 完毕 ， 程 序 运行 最 终 返 区 


总 结 


IOA 


4.15 


本 章 从 源码 的 角度 深度 分 析 了 Docker Daemon 启 动 过 程 中 daemon 对 象 的 创建 与 加 载 。 在 这 一 环节 中 涉及 内 容 极 多 ， 本 章 着 重 归纳 总 结 daemon 实 现 的 逻辑 ， 一 一 深入 ， 


} 函 数 。 在 该 函数 中 ， 主 要 完成 以 下 4 部 分 操作 : 


至 mainDaemon () 中 ， 继 续 通 过 goroutine 完 成 加 载 daemon。 


体 全 面 。 


在 Docker 的 架构 中 ，Docker Daemon 的 内 容 是 最 为 丰富 全 面 的 ， 而 NewDaemon 的 实现 涵盖 了 Docker Daemon 启 动 过 程 中 的 大 部 分 工作 。 可 以 认为 NewDaemon 是 Docker Daemon 实 现 过 程 中 的 


核心 所 在 。 深 入 理解 NewDaemon 的 实现 ， 即 掌握 了 Docker Daemon 运 行 的 来 龙 去 脉 。 


第 5 章 Docker Server 的 创建 


5.1 


引言 


Docker 架 构 中 ，Docker Server 是 Docker Daemon 的 重要 组 成 部 分 。Docker Server 最 主要 的 功能 是 : 接收 | 


请 求 处 理 后 的 结果 返回 至 Docker Client。 


备 十 分 优秀 的 用 户 友好 性 ， 多 种 通信 协议 的 支持 大 大 降低 Docker 


同时 ，Docker Server. 


户 使 


Docker 的 


通信 安全 方面 ，Docker Server 可 以 提供 安全 传输 层 协 议 (TLS) ， 保 证 Docker Client 与 Docker Server 之 间 数 据 | 


大 提高 了 服务 端 对 于 请 求 的 并 发 处 理 能 力 。 
本 章 将 从 源码 的 角度 分 析 Docker Server 的 创建 ， 分 析 内 容 的 安排 如 下 : 
1) 介绍 Job“serveapi” 的 创建 与 执行 流程 ， 代 表 Docker Server 的 创建 。 
2) 深入 分 析 Job “serveapi” 的 执行 流程 。 


3) 分 析 Docker Server 创 建 Listener 并 服务 API 的 流程 。 


第 5 章 


5.1 


引言 


门槛 。 除 此 之 外 ，Docker Server 设 计 实现 了 详尽 清晰 的 API| 接 


户 通过 Docker Client 发 送 的 请 求 ， 并 按照 相应 的 路 由 规则 实现 请 求 的 路 由 分 发 ， 最 终 将 


， 以 供 Docker 用 户 使 用 。 
了 Go 语言 中 的 协 程 goroutine， 大 


的 加 密 传输 。 并 发 处 理 方面 ，Docker Daemon 大 量 使 有 


Docker Server 的 创建 


Docker 架 构 中 ，Docker Server 是 Docker Daemon 的 重要 组 成 部 分 。Docker Server 最 主要 的 功能 是 : 接收 | 


户 通过 Docker Client 发 送 的 请 求 ， 并 按照 相应 的 路 由 规则 实现 请 求 的 路 由 分 发 ， 最 终 将 


请 求 处 理 后 的 结果 返回 至 Docker Client。 


同时 ，Docker Server 具 备 十 分 优秀 的 用 户 友好 性 ， 多 种 通信 协议 的 支持 大 大 降低 Docker 用 户 使 用 Docker 的 门槛 。 除 此 之 外 ，Docker Server 设 计 实现 了 详尽 清晰 的 API 接 口 ， 以 供 Docker 用 户 使 用 。 
通信 安全 方面 ，Docker Server 可 以 提供 安全 传输 层 协议 (TLS) ， 保 证 Docker Client 与 Docker Server 之 间 数 据 的 加 密 传输 。 并 发 处 理 方面 ，Docker Daemon 大 量 使 用 了 Go 语言 中 的 协 程 goroutine， 大 
大 提高 了 服务 端 对 于 请 求 的 并 发 处 理 能 力 。 


本 章 将 从 源码 的 角度 分 析 Docker Server 的 创建 ， 分 析 内 容 的 安排 如 下 : 
1) 介绍 Job “serveapi” 的 创建 与 执行 流程 ， 代 表 Docker Server 的 创建 。 
2) 深入 分 析 Job “serveapi” 的 执行 流程 。 


3) 分 析 Docker Server 创 建 Listener 并 服务 API 的 流程 。 


5.2 Docker Server 创 建 流程 


我 们 在 第 3 章 主要 分 析 了 Docker Daemon 的 启动 ， 而 在 mainDaemon () 运行 的 最 后 环节 ，Docker 实 现 了 创建 并 运行 名 为 serveapi 的 Job。 这 一 环节 的 作用 是 : 让 Docker Daemon 提 供 API 访 问 服 
务 。 实 质 上 ， 这 正 是 实现 了 Docker 架 构 中 Docker Server 的 创建 与 运行 。 


从 流程 的 角度 来 说 ，Docker Server 的 创建 与 运行 ， 代 表 了 Job“serveapi” 的 整个 生命 周期 。 整 个 生命 周期 包括 : 创建 Docker Server 的 Job， 配 置 Job 环 境 变量 ， 以 及 触发 执行 Job。 


5.3 ”ServeApi 运 行 流程 


ServeApi 属 于 Docker Server 提 供 API 服 务 的 部 分 ， 本 小 节 将 从 源码 的 角度 剖析 Docker Server 的 架构 设计 与 实现 。 


作为 一 个 监听 请 求 、 处 理 请 求 、 响 应 请 求 的 服务 端 ，Docker Server 首 先 需要 明确 自身 可 以 为 多 少 种 通信 协议 提供 服务 。 稍 加 深入 学 习 Docker 这 个 C/S 模 式 的 架构 设计 ， 就 可 以 发 现 Docker Server 支 持 
的 协议 包括 以 下 三 种 : TCP 协 议 、UNIX Socket 形 式 以 及 fd 的 形式 。 随 后 ，Docker Server 根 据 协议 的 不 同 ， 分 别 创建 不 同 的 服务 端 实例 。 最 后 ， 在 不 同 的 服务 端 实例 中 ， 创 建 相应 的 路 由 模块 、 监 听 模 块 ， 
以 及 处 理 请 求 的 处 理 方法 ， 形 成 一 个 完备 的 服务 端 。 


serveapi 这 个 Job 在 运行 时 ， 将 执行 api.ServeApi 函 数 。ServeApi 的 功能 是 : 循环 检查 Docker Daemon 当 前 支持 的 所 有 通信 协议 ， 并 为 每 一 种 协议 都 创建 一 个 协 程 goroutine， 并 在 此 协 程 内 部 配置 一 
个 服务 于 HTTP 请 求 的 服务 端 。ServeApi 的 源码 实现 位 于 ./docker/docker/api/server/server.go#L1339， 如 下 所 示 : 


func ServeApi(job *engine.Job) engine.Status ( 
if len(job.Args) == 0 ( 
return job.Errorf("usage: $s PROTO://ADDR [PROTO://ADDR http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/15329/OEBPS/Text/...]", 
} 
var ( 
protoAddrs = job.Args 
chErrors = make (chan error, len(protoAddrs)) 


activationLock = make (chan struct{}) 
for _, protoAddr := range protoAddrs { 
protoAddrParts := strings.SplitN(protoAddr, "://", 2) 
if len(protoAddrParts) != 2 ( 
return job.Errorf("usage: $s PROTO://ADDR [PROTO://ADDR http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/15329/OEBPS/Text./ . 


j 
go func() { 
log.Infof("Listening for HTTP on $s ($s)", protoAddrParts[0], protoAddrParts[1]) 
chErrors «- ListenAndServe (protoAddrParts[0], protoAddrParts[1], job) 
10 
) 
for i := 0; i < len(protoAddrs); i += 1 ( 
err := «-chErrors 
if err != nil ( 


return job.Error (err) 


} 


return engine.StatusOK 


分 析 以 上 源码 ， 通 过 模块 化 的 划分 ， 我们 可 以 发 现 ServeApi 的 执行 流程 主要 分 为 以 下 4 个 步骤 : 
1) 检验 Job 的 参数 ， 确 保 传 入 参数 无 误 。 
2) 定义 Docker Server 的 监听 协议 与 地 址 ， 以 及 错误 信息 管道 channel。 


3) 遍历 协议 地 址 ， 针 对 协议 创建 相应 的 服务 端 。 


4) 通过 chErrors 建 立 goroutine 与 主 进程 之 间 的 协调 关系 。 


下 面 详细 分 析 以 上 4 个 步骤 : 


第 一 ，Docker Daemon 判 断 Job 的 参数 ， 保 证 传 入 的 Job 参 数 无 误 。DockerDaemon 判 断 的 依据 来 源 于 job.Args 的 长 度 。 由 于 Docker 创 建 serveapi 这 个 Job 时 ， 通 过 flHosts 来 初始 化 job.Args, 故 
job.Args 为 相当 于 数组 flIHost， 若 flHost 的 长 度 为 0， 则 说 明 Docker Server 没 有 监听 的 协议 与 地 址 ， 参 数 有 误 ， 返 回 错误 信息 。 源 码 如 下 : 


if len(job.Args) == 0 ( 
return job.Errorf("usage: $s PROTO://ADDR [PROTO://ADDR http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/15329/OEBPS/Text/...]", job. 
} 


第 二 ， 定 义 protoAddrs、chErrors 与 activationLock 三 个 变量 ， 分 别 代表 Docker Server 监 听 的 协议 与 地 址 ， 以 及 Job 间 的 同步 channel。 


protoAddrs 代 表 flHosts 的 内 容 ; 而 chError 定 义 了 和 protoAddrs 长 度 一 致 的 错误 类 型 管道 ，chError 的 作用 会 在 下 文中 说 明 。 同 时 定义 的 变量 activationLock， 是 用 以 同步 serveapi 和 
acceptconnections 这 两 个 Job 执 行 的 管道 。serveapi 运 行 时 ，ServeFd 和 ListenAndServe 函 数 均 由 于 activationLock 中 没有 内 容 而 阻塞 ， 而 当 运 行 acceptionconnections 这 个 Job 时 ， 该 Job 会 首先 通知 init 
进程 Docker Daemon 已 经 启动 完毕 ， 并 关闭 activationLock， 因 此 ServeFd 以 及 ListenAndServe 不 再 阻塞 ， 结 果 是 serveapi 继 续 执行 。 正 是 由 于 activationLock 的 存在 ，Docker Daemon 可 以 保证 


acceptconnections 这 个 Job 的 运行 有 能 力 通 知 serveapi 开 启 正式 服务 于 API 请 求 的 功能 。 源 码 如 下 : 


var ( 

protoAddrs = job.Args 

chErrors = make (chan error, len(protoAddrs)) 
) 


activationLock = make (chan struct(]) 


第 三 ， 遍 历 协 议 地 址 ， 针 对 协议 创建 相应 的 服务 端 。 协 议 地 址 即 protoAddrs， 也 就 是 job.Args。DockerDaemon 将 protoAddrs 的 每 一 元 素 都 按照 字符 串 “: /上 ”进行 分 割 ， 若 分 割 后 protoAddrParts 
的 长 度 不 为 2， 则 说 明 协议 地 址 的 书写 形式 有 误 ， 返 回 Job 错 误 ; 若 分 割 后 protoAddrParts 的 长 度 为 2， 则 说 明 地 址 协议 符合 标准 ， 获 取 protoAddrParts 中 的 协议 protoAddrParts[0] 与 地 址 
protoAddrParts[1]。 最 后 ， 针 对 每 一 次 循环 中 获得 的 协议 与 地 址 ，Docker Daemon 均 创建 一 个 goroutine 来 执行 ListenAndServe 的 操作 。goroutine 的 运行 主要 依赖 于 
ListenAndServe (protoAddrParts[0], protoAddrParts[1], job) 的 运行 结果 。 若 ListenAndServe 返 回 错误 ， 则 chErrors 中 有 错误 ， 当 前 协 程 执行 完毕 ; 若 没 有 返回 错误 ， 则 该 协 程 持续 运行 ， 持 续 提供 
服务 。 其 中 最 为 重要 的 是 ListenAndServe 的 实现 ， 该 函数 具体 实现 了 Docker Daemon 如 何 创建 listener、router 以 及 server， 并 协调 三 者 进行 工作 ， 最 终 服 务 于 API 请 求 。 步 又 三 的 源码 实现 如 下 : 


for , protoAddr := range protoAddrs { 
protoAddrParts :- strings.SplitN(protoAddr, "://", 2) 
if len(protoAddrParts) != 2 ( 
return job.Errorf("usage: $s PROTO://ADDR [PROTO://ADDR http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/15329/OEBPS/Text/...]", 


) 

go func() ( 
log.Infof("Listening for HTTP on $s ($s)", protoAddrParts[0], protoAddrParts[1]) 
chErrors <- ListenAndServe (protoAddrParts[0], protoAddrParts[1], job) 

)0 


第 四 ， 根 据 chErrors 的 值 运行 ， 若 chErrors 这 个 管道 中 有 错误 内 容 ， 则 ServeApi 的 一 次 循环 结束 ; 若 无 错 误 内 容 ， 则 循环 被 阻塞 。chErrors 这 个 管道 的 作用 是 : 确保 ListenAndServe 所 对 应 的 协 程 能 和 
主 函 数 ServeApi 进 行 协调 ， 如 果 协 程 运行 出 错 ， 主 函数 ServeApi 仍 然 可 以 捕获 这 样 的 错误 ， 从 而 导致 程序 的 退出 。 实 现 源码 如 下 : 


for i := 0; i < len(protoAddrs); i += 1 { 
err := «-chErrors 
if err != nil ( 
return job.Error (err) 
) 
l 


return engine.StatusOK 


至 此 ，ServeApi 的 运行 流程 已 经 全 部 分 析 完 毕 ， 其 中 核心 部 分 ListenAndServe 的 实现 ， 将 在 5.4 节 深入 分 析 。 


5.4 ListenAndServe 实 现 


ListenAndServe 的 功能 是 : 使 Docker Server 监 听 某 一 指定 地 址 ， 并 接收 该 地 址 上 的 请 求 ， 并 对 以 上 请 求 路 由 转发 至 相应 的 处 理 方法 处 。 从 实现 的 角度 来 看 ，ListenAndServe 主 要 实现 了 设置 一 个 服务 
于 HTTP 协 议 请 求 的 服务 端 ， 该 服务 端 监 听 指 定 地 址 上 的 请 求 ， 并 对 请 求 做 特定 的 协议 检查 ， 最 终 完成 请 求 的 路 由 与 分 发 。 代 码 实现 位 于 ./docker/docker/api/server/server.go。 


ListenAndServe 的 实现 可 以 分 为 以 下 4 个 部 分 : 
1) 创建 router 路 由 实例 。 

2) 创建 listener 监 听 实 例 。 

3) 创建 http.Server。 


4) 启动 API 服 务 。 


ListenAndServe 的 执行 流程 如 图 5-1 所 示 。 


I:-listenbuffer. 
NewListenButfer i! 


httpsrv := http. 


SpPrver:jimddr, r 


return return 
httpsrv. 5erveli] serveFDtaddr, r) 


图 5-1 ListenAndServe 执 行 流程 区 


本 节 将 按照 ListenAndServe 执 行 流程 图 一 一 深入 分 析 各 个 部 分 。 


5.5 总结 


Docker Server 作 为 Docker Daemon 架 构 中 请 求 的 入 口 ， 接 管 了 Docker Client 与 Docker Daemon 之 间 所 有 的 通信 。 通 信 API 的 规范 性 ， 通 信 过 程 的 安全 性 ， 服 务 请 求 的 并 发 能 力 ， 往 往 都 是 Docker, 
户 最 为 关心 的 内 容 。 本 章 基于 Docker 源 码 ， 分 析 了 Docker Server 大 部 分 的 细节 实现 。 希 望 Docker 用 户 可 以 初探 Docker Server 的 设计 理念 ， 并 且 可 以 更 好 地 利用 Docker Server 创 造 更 大 的 价值 。 


第 6 章 Docker Daemon 网 络 


6.1 引言 


Docker 作 为 一 个 开源 的 轻 量 级 虚拟 化 容器 引擎 技术 ， 已 然 给 云 计算 领域 带 来 全 新 的 发 展 模式 。Docker 借 助 容器 技术 彻底 释放 了 轻 量 级 虚拟 化 技术 的 威力 ， 让 容器 的 伸缩 、 应 用 的 运行 都 变 得 前 所 未 有 
的 方便 与 高 效 。 同 时 ，Docker 借 助 强大 的 镜像 技术 ， 让 应 用 的 分 发 、 部 署 与 管理 变 得 史无前例 的 便捷 。 然 而 ，Docker 毕 竟 是 一 项 较为 新 颖 的 技术 ， 在 Docker 的 世界 中 ， 用 户 并 非 一 劳 永 逸 ， 其 中 最 为 业界 


所 诉 病 的 便 是 Docker 的 网 络 问题 。 


毋 庸 置疑 ， 对 于 Docker 管 理 者 和 开发 者 而 言 ， 如 何 有 效 、 高 效 地 管理 Docker 容 器 之 间 的 交互 以 及 Docker 容 器 的 网 络 一 直 是 一 个 巨大 的 挑战 。 目 前 ， 云 计算 领域 中 ， 绝 大 多 数 系统 都 采取 分 布 式 技术 来 
设计 并 实现 。 然 而 ， 在 原生 态 的 Docker 世 界 中 ，Docker 的 网 络 却 不 具备 跨 宿主 机 的 能 力 ， 这 也 或 多 或 少 制约 着 Docker 在 云 计算 领域 的 高 速 发 展 。 


Docker 网 络 问题 的 解决 势 在 必 行 ， 面 对 不 同 的 应 用 场景 ， 不 少 IT 企业 都 开发 了 各 自 的 新 产品 来 帮助 完善 Docker 的 网 络 。 这 些 企业 中 不 过 像 Google 一 样 的 互联 网 撼 楚 ， 同 时 也 有 不 少 初创 企业 率先 出 
击 ， 在 最 前 沿 不 懈 探 索 。 这 些 新 产品 包括 : Google 推 出 的 容器 管理 和 编排 工具 Kubernetes，Zett.io 公 司 开发 的 通过 虚拟 网 络 连 接 跨 宿主 机 容器 的 工具 Weave，CoreOS 团 队 针 对 Kubernetes 设 计 的 网 络 覆 
工具 Flannel，Docker 官 方 的 工程 师 Jérbme Petazzoni 自 己 设 计 的 SDN 网 络 解 决 方案 Pipework， 以 及 SocketPlane 项 目 等 。 


对 于 Docker 管 理 者 与 开发 者 而 言 ， 虽 然 Docker 的 跨 宿主 机 通信 能 力 暂 时 不 够 完善 ， 但 了 解 Docker 自 身 的 网 络 架构 也 是 很 有 必要 的 。 只 有 深入 了 解 Docker 自 身 的 网 络 设计 与 实现 ， 才 能 清楚 其 头 端 ， 


从 而 扩展 Docker 的 跨 宿主 机 能 力 。 


Docker 自 身 的 网 络 主要 包含 两 部 分 : Docker Daemon 的 网 络 配置 、Docker 容 器 的 网 络 配置 。 本 章 主要 从 源码 的 角度 ， 分 析 Docker Daemon 在 启动 过 程 中 ， 为 Docker 配 置 的 网 络 环境 ， 内 容 安排 如 


F: 


1) Docker Daemon 网 络 配置 。 


2) 运行 Docker Daemon 网 络 初始 化 任务 。 


3) 创建 Docker 网 桥 。 


第 6 章 Docker Daemon 网 络 


6.1 引言 


Docker 作 为 一 个 开源 的 轻 量 级 虚拟 化 容器 引擎 技术 ， 已 然 给 云 计算 领域 带 来 全 新 的 发 展 模式 


。Docker 借 助 容器 技术 彻底 释放 了 轻 量 级 虚拟 化 技术 的 威力 ， 让 容器 的 伸缩 、 应 用 的 运行 都 变 得 前 所 未 有 


的 方便 与 高 效 。 同 时 ，Docker 借 助 强 大 的 镜像 技术 ， 让 应 用 的 分 发 、 部 署 与 管理 变 得 史无前例 的 便捷 。 然 而 ，Docker 毕 竟 是 一 项 较为 新 颖 的 技术 ， 在 Docker 的 世界 中 ， 用 户 并 非 一 劳 永 逸 ， 其 中 最 为 业界 


所 诉 病 的 便 是 Docker 的 网 络 问题 。 


毋 庸 置疑 ， 对 于 Docker 管 理 者 和 开发 者 而 言 ， 如 何 有 效 、 高 效 地 管理 Docker 容 器 之 间 的 交互 以 及 Docker 容 器 的 网 络 一 直 是 一 个 巨大 的 挑战 。 目 前 ， 云 计算 领域 中 ， 绝 大 多 数 系统 都 采取 分 布 式 技术 来 
设计 并 实现 。 然 而 ， 在 原生 态 的 Docker 世 界 中 ，Docker 的 网 络 却 不 具备 跨 宿主 机 的 能 力 ， 这 也 或 多 或 少 制约 着 Docker 在 云 计算 领域 的 高 速 发 展 。 


Docker 网 络 问题 的 解决 势 在 必 行 ， 面 对 不 同 的 应 用 场景 ， 不 少 !T 企 业 都 开发 了 各 自 的 新 产品 来 帮助 完善 Docker 的 网 络 。 这 些 企 业 中 不 过 像 Goo0gle 一 样 的 互联 网 撼 楚 ， 同 时 也 有 不 少 初创 企业 率先 出 
击 ， 在 最 前 沿 不 懈 探 索 。 这 些 新 产品 包括 : Google 推 出 的 容器 管理 和 编排 工具 Kubernetes，Zett.io 公 司 开发 的 通过 虚拟 网 络 连 接 跨 宿主 机 容器 的 工具 Weave，CoreOS 团 队 针 对 Kubernetes 设 计 的 网 络 覆 
工具 Flannel，Docker 官 方 的 工程 师 Jérbme Petazzoni 自 己 设 计 的 SDN 网 络 解 决 方案 Pipework， 以 及 SocketPlane 项 目 等 。 


对 于 Docker 管 理 者 与 开发 者 而 言 ， 虽 然 Docker 的 跨 宿主 机 通信 能 力 暂 时 不 够 完善 ， 但 了 解 Docker 自 身 的 网 络 架构 也 是 很 有 必要 的 。 只 有 深入 了 解 Docker 自 身 的 网 络 设计 与 实现 ， 才 能 清楚 其 头 端 ， 


从 而 扩展 Docker 的 跨 宿主 机 能 力 。 


Docker 自 身 的 网 络 主要 包含 两 部 分 : Docker Daemon 的 网 络 配置 、Docker 容 器 的 网 络 配置 。 本 章 主要 从 源码 的 角度 ， 分 析 Docker Daemon 在 启动 过 程 中 ， 为 Docker 配 置 的 网 络 环境 ， 内 容 安排 如 


下 : 


1) Docker Daemon 网 络 配置 。 
2) 运行 Docker Daemon 网 络 初始 化 任务 。 


3) 创建 Docker 网 桥 。 


6.2 Docker Daemon 网 络 介绍 


在 Docker 环 境 中 ，Docker 容 器 的 网 络 能 力 一 直 备 受 关心 。 对 一 个 Docker 容 器 而 言 ， 它 可 以 独 享 内 部 的 网 络 栈 ， 并 与 其 他 容器 分 处 隔离 的 网 络 环境 。 然 而 作为 DockerDaemon 创 建 的 容器 ， 容 器 与 宿主 


机 之 外 建立 通信 时 ， 仍 然 无 可 避免 地 通过 宿主 机 物理 网 卡 或 者 虚拟 机 的 eth0 虚 拟 网 卡 。 既然 如 此 ， 


那么 如 何 构建 Docker 容 器 与 宿主 机 之 间 的 网 络 拓扑 ， 将 是 一 个 学 习 Docker 网 络 时 必须 理解 的 关键 点 。 


在 一 台 没有 安装 Docker 的 宿主 机 上 ， 网 络 环境 很 有 可 能 平淡 无 奇 。 然 而 ， 当 用 户 开 始 安装 并 
络 模式 。 


关于 Docker 的 网 络 模式 ， 大 家 最 熟知 的 应 该 就 是 “桥接 ”模式 ， 也 被 称 为 bridge 模 式 。 在 桥 
6-1 所 示 。 


启动 Docker 时 ， 一 切 发 生 了 变化 。 而 Docker 管 理 员 完全 有 权限 在 启动 Docker 时 配置 Docker Daemon 的 网 


接 模式 下 ，Docker 的 网 络 环境 拓扑 (包括 Docker Daemon 网 络 环境 和 Docker Container 网 络 环境 ) 如 


IR] 


ethÜ 


dockerO0 (bridge) 


ipv4 ip forward 


图 6-1 Docker 网 络 桥接 模式 示意 图 


然而 ，“ 桥 接 ” 模 式 是 Docker 网 络 模式 中 最 为 常 


的 模式 。 除 此 之 外 ，Docker 还 为 用 户 提供 了 更 多 的 可 选项 ， 本 章 余 下 部 分 将 进行 深入 分 析 。 


6.3 Docker Daemon 网 络 配置 接口 


Docker Daemon 每 次 启动 的 过 程 中 ， 都 会 初始 化 自身 的 网 络 环境 。 初 始 化 后 的 网 络 环境 最 终 为 Docker 容 器 提供 网 络 通信 服务 。 为 了 实现 Docker Daemon 网 络 的 初始 化 ，Docker 管 理 员 可 以 在 启动 


Docker Daemon 时 ， 通 过 参数 的 形式 配置 Docker 的 网 


其 中 ， 涉 及 的 flag 参 数 有 Enablelptables、Enable 


络 环境 。 配 置 参数 可 以 通过 运行 docker 二 进 制 可 执行 文件 来 完成 ， 即 通过 运行 docker-d 并 添加 其 他 与 网 络 相关 的 flag 参 数 来 完成 。 


IpForward、Bridgelface、BridgelP 以 及 InterContainerCommunication。 这 5 个 与 网 络 相关 的 flag 参 数 的 定义 位 


于 ./docker/docker/daemon/config.go#L49-L53, 


体 源码 如 下 : 


flag.BoolVar(&config.EnableIptables, []string{"#iptables", "-iptables"}, true, "Enable Docker's addition of iptables rules") 


flag.BoolVar(&config.EnableIpForward, []string("fip-forward", "-ip-forward"), true, "Enable net.ipv4.ip forward") 

flag.StringVar(&config.BridgeIP, []string("4bip", "-bip"), "", "Use this CIDR notation address for the network bridge's IP, not compatible with -b") 
flag.StringVar(&config.Bridgelface, []string("b", "-bridge"), "", "Attach containers to a pre-existing network bridgeWnuse 'none' to disable container networking") 
flag.BoolVar(&config.InterContainerCommunication, []string("£icc", "-icc"), true, "Enable inter-container communication") 


以 下 介绍 这 5 个 flag 参 数 的 作 


: EnableIptables: 确保 Docker Daemon 启 动 时 ， 能 对 宿主 机 上 的 iptables 规 则 进行 修改 。 


“ EnableIpForward: 确保 net.ipv4.ip_forward 功 能 开启 ， 使 得 宿主 机 在 多 网 络 接 口 模式 下 ， 数 据 包 可 以 在 网 络 接 口 之 间 转 发 。 


- BridgeIP: Docker Daemon 为 网 络 环境 中 的 网 桥 配 


置 的 CIDR 网 络 地 址 。 


“ Bridgelface: 为 Docker 网 络 环境 指定 具体 的 通信 网 桥 ， 若 Bridgelface 的 值 为 one， 则 说 明 不 需要 为 Docker 容 器 创建 网 桥 服务 ， 关 闭 Docker 容 器 的 网 络 能 力 。 


- InterContainerCommunication: 确保 Docker 容 器 之 


间 可 以 完成 通信 ， 通 过 防火 墙 完成 。 


除 DockerDaemon 会 使 用 到 的 5 个 flag 参 数 之 外 ，Docker 在 创建 网 络 环境 时 ， 还 使 用 一 个 DefaultlP 变 量 ， 如 下 所 示 : 


opts.IPVar (&config.DefaultIp, []string{"#ip", 


"-ip"), "0.0.0.0", "Default IP address to use when binding container ports") 


该 变量 的 作用 是 : 绑 定 Docker 容 器 的 端口 与 宿主 机 上 的 某 一 个 端口 时 ， 将 Defaultip 作 为 默认 使 用 的 宿主 机 IP 地 址 。 


为 BridgelP 和 Bridgelface。 举 例 说 明 如 表 6-1 所 示 。 


具备 以 上 Docker Daemon 的 网 络 背 景 知识 之 后 ， 我 们 来 分 析 如 何 通 过 docker 二 进 制 文件 启动 Docker Dameon 并 配置 相应 的 网 络 环境 。Docker Daemon 的 网 络 环境 和 两 个 flag 参 数 相关 性 最 大 ， 分 别 


表 6-1 Docker Daemon 启 动 命令 表 


启动 Docker Daemon 命令 作用 分 析 


docker -d 启动 Docker Daemon， 使 用 默认 网 桥 docker0， 不 指定 CIDR 网 络 地 址 
docker -d -b-"xxx" 启动 Docker Daemon， 使 用 网 桥 xxx， 不 指定 CIDR 网 络 地 址 
docker -d --bip="172.17.42.1" 启动 Docker Daemon， 使 用 默认 网 桥 docker0， 使 用 指定 CIDR 网 络 


地 址 172.17.42.1 
docker -d --bridge-"xxx" --bip="10.0.42.1" 报错 ， 出 现 兼容 性 问题 ， 不 能 同时 指定 BridgeIP 和 Bridgelface 
docker -d --bridge="none" 启动 Docker Daemon， 不 创建 Docker 网 络 环境 


深入 理解 Bridgelface 与 BridgelP， 并 熟练 使 用 相应 的 flag 参 数 ， 就 能 做 到 配置 Docker Daemon 的 网 络 环境 。 需 要 特别 注意 的 是 ，Docker Daemon 的 网 络 与 Docker 容 器 的 网 络 存在 很 大 的 区 别 。 
Docker Daemon 为 Docker 容 器 创建 网 络 的 大 环境 ，Docker 容 器 的 网 络 需要 Docker Daemon 的 网 络 提供 支持 ， 但 不 唯一 。 举 一 个 形象 的 例子 ，Docker Daemon 可 以 创建 docker0 网 桥 ， 为 之 后 Docker 容 
器 的 桥接 模式 提供 支持 ; 然而 在 桥接 模式 下 ，Docker 容 器 可 以 启用 桥接 ， 转 而 根据 用 户 需 求 创建 自身 网 络 。 其 中 Docker 容 器 的 网 络 可 以 是 桥接 模式 的 网 络 ， 同 时 也 可 以 直接 共享 宿主 机 的 网 络 设 备 ， 另 外 
还 有 其 他 模式 。 关 于 Docker 容 器 的 网 络 ， 将 在 第 7 章 进行 详细 介绍 。 


6.4 Docker Daemon 网 络 初始 化 


正如 上 一 节 所 言 ，Docker 管 理 员 可 以 通过 与 网 络 相关 的 flag 参 数 Bridgelface 与 BridgelP， 来 为 Docker Daemon 创 建 网 络 环境 。 最 简单 的 ，Docker 管 理 员 通过 执行 "docker-d" 就 已 经 完成 Docker 


Daemon 的 运行 。 


Docker Daemon 网 络 初始 化 流程 如 


6-2 所 示 。 


D 


flag. Parse t) 


config. BridgelP (default: 
eonfig. Bridgelface default: 


T LI 
none 


[i sableNetworkBridge 


config: Bridgelface 
DisahleNetworkBridge 


config. DisableNetwork-true 


config.DisableNetwork-false 


!'cranfig.DisableMetwork 


Do Mothing 


eng, Jobi "init networkdriver" ] 


job : 


job. Run Q 
(InitDriver) 


图 6-2 Docker Daemon 网 络 初始 化 流程 图 
流程 图 中 可 知 ，Docker Daemon 创 建 网 络 环境 时 有 两 个 分 支 ， 不 难 发 现 分 支 代表 的 分 


居 解 析 flag 参 数 来 决定 到 底 建 立 哪 种 类 型 的 网 络 环境 。 从 


总 体 而 言 ，Docker Daemon 网 络 的 初始 化 流程 主要 是 根 所 
别 是 : 为 Docker 创 建 一 个 网 络 驱 动 ， 以 及 对 Docker 的 网 络 不 做 任何 操作 
图 具体 分 析 实现 步 又。 


下 面 参照 Docker Daemon 网 络 初始 化 流程 


6.5 ”创建 Docker 网 桥 
的 模式 为 桥接 模式 。 本 节 将 详细 分 析 Docker 网 桥 的 创建 流程 。 


Docker 的 网 络 往往 是 Docker 开 发 者 最 常 提起 的 话题 。 而 Docker 网 络 中 最 常 使 
Docker 网 桥 的 创建 通过 init_network 这 个 Job 的 运行 来 完成 。init_network 的 实现 为 InitDriver 函 数 ， 位 于 ./docker/docker/daemon/networkdriver/bridge/driver.go#L79，|nitDriver 浮 数 的 运行 流 


程 如 图 6-3 所 示 。 
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图 6-3 Docker Daemon 创 建 网 桥 流程 图 


在 工业 界 ，Docker 的 网 络 问题 备 受 关注 。Docker 的 容器 技术 以 及 镜像 技术 ， 已 


展 。 


经 给 Docker 实 践 者 带 来 了 诸多 效益 。 然 而 Docker 网 络 的 发 展 依然 


Docker 的 网 络 环境 可 以 分 为 Docker Daemon 网 络 和 Docker Container 网 络 。 本 章 从 Docker Daemon 的 网 络 入 手 ， 分 析 了 大 家 熟知 的 Docker 桥 接 模式 。 


7.1 引言 
如 今 ，Docker 技 术 风 靡 全 球 ， 大 家 在 尝试 以 及 玩 转 Docker 的 同时 ， 肯 定 离 不 开 一 个 概念 ， 
第 一 次 接触 Docker 时 ， 大 家 肯定 会 深 深 感 受到 : 在 Docker 容 器 内 部 运行 应 用 程序 竟 是 如 


对 不 是 天 方 夜 谭 ; 第 二 ，Docker 容 器 内 运行 的 应 


毋庸 置疑 ，Docker 的 一 些 特 性 ， 的 确 据 弃 了 传统 情况 下 开发 模式 的 不 少 浆 端 。 然 而 ， 这 强大 的 功能 背后 到 底 是 何等 技术 在 “ 作 崇 ”， 又 是 谁 可 以 支撑 Docker 


那 就 Linux 内 核 。 


那 我 们 就 从 Linux 内 核 的 角度 来 看 看 Docker 到 底 为 何 物 ， 先 从 Docker 容 器 入 手 。 对 了 
后 者 肯定 也 是 工业 界 称 之 为 “容器 ”的 原因 之 一 。 


者 。 以 下 将 慢 慢 阐述 其 中 的 原 


第 7 章 Docker 容 器 网 络 


程序 还 可 以 受到 资源 的 控制 与 隔离 ， 大 大 


因 。 


足 云 计算 时 代 应 


阐述 问题 “容器 是 否 可 以 


涪 离 进 程 而 存在 ”的 原 


因 前 ， 相 信 大 家 对 于 下 


么 问题 在 于 ， 容 器 到 底 是 通过 什么 途径 来 实现 进程 组 运行 环境 的 “隔离 ” 呢 ? 此 时 ， 就 轮 到 Linux 内 核 隆重 登场 了 。 


说 到 运行 环境 的 “隔离 ” 
核 特性 联合 使 


， 才 保证 了 Docker 容 器 之 间 


， 相 信 大 


1) 父 进 程 通 过 fork 创 建 子 


进程 时 ， 使 F 


2) 子 进程 创建 完毕 之 后 ， 


3) namespaces 和 cgrou 


从 Linux 内 核 的 角度 分 析 容器 
是 : 容器 不 能 脱离 进程 而 存在 ， 先 有 进程 ， 后 有 容器 。 然 而 ， 大 家 往往 会 说 到 “使 


肯定 对 Linux 内 核 中 的 namespaces 和 cgroups 略 有 1 
的 “隔离 ”。 那 么 ，namespaces 和 cgroups 又 和 进程 有 什么 关系 呢 ? 问题 的 答案 可 以 


namespaces 技 术 ， 实 现 子 进程 与 父 


使 用 cgroups 技 术 来 处 理 进 程 ， 实 现 进程 的 资源 限制 。 


ps 这 两 种 技术 都 上 


上 之 后 ， 进 程 所 处 的 “隔离 ”环境 才 真正 建立 ， 此 时 “容器 ”真正 诞生 


器 ”一 词 的 存在 ， 本 身 就 较为 抽象 。 如 果 需 要 更 为 准确 ， 可 以 表述 为 “使 


Docker 创 建 Docker 容 器 ， 然 


FF Docker 容 器 ， 体 验 过 的 开发 者 都 有 两 点 非常 重 


耳闻 ，namespaces 主 要 负责 命名 空间 的 | 


: 内 部 可 以 跑 应 


的 感 


以 下 的 次 序 来 表示 : 


进程 以 及 其 他 进程 之 间 命 名 空间 的 隔离 。 


后 在 容器 内 部 运行 进程 ” 


局 离 ，cgroups 主 要 负责 资源 使 用 的 限制 。 


有 很 大 的 潜力 ， 依 然 值 得 大 家 不 断 探索 并 推动 其 发 


那 就 是 “容器 ”或 者 “Container”。 那 么 我 们 首先 从 原理 的 角度 一 帘 “ 容 器 ”或 者 “Container” 的 究竟 。 


方便 。 第 一 ， 应 用 程序 在 Docker 容 器 内 部 的 部 署 与 运行 非常 便捷 ， 只 要 有 Dockerfile， 应 
的 要 求 。 


的 运行 并 提供 丰富 的 特性 ? 答案 很 简单 ， 


一 键 式 的 部 署 绝 


的 诞生 ， 精 简 的 流程 即 如 上 三 步 ， 而 这 三 个 步骤 也 恰好 巧妙 地 阐述 了 namespaces 和 cgroups 这 两 种 技术 和 进程 的 关系 ， 以 及 进程 与 容器 的 关系 。 进 程 与 容器 的 关系 ， 


(进程 ) ， 以 及 提供 隔离 的 环境 。 当 然 ， 


首先 ， 我 们 先 来 看 Docker 容 器 与 进程 的 关系 ， 或 者 容器 与 进程 的 关系 。 为 了 理 清 这 两 者 之 间 的 关系 ， 我 不 妨 提出 这 样 一 个 问题 “容器 是 否 可 以 脱离 进程 而 存在 ”。 换 名 话说 就 是 ， 能 否 创建 一 个 容器 ， 
而 这 个 容器 内 部 没有 任何 进程 。 答 案 是 否定 的 。 既 然 答案 是 否定 的 ， 说 明 不 可 能 先 有 容器 ， 然 后 再 有 进程 ， 那 么 问题 又 来 了 ，“ 容 器 和 进程 是 一 起 诞生 的 ， 还 是 先 有 进程 再 有 容器 呢 ? ”可 以 说 答案 是 后 


面 这 段 话 不 会 有 异议 : 通过 Docker 创 建 出 的 一 个 Docker Container 是 一 个 容器 ， 而 这 个 容器 提供 了 进程 组 隔离 的 运行 环境 。 那 


其 实 ， 正 是 这 两 个 神奇 的 内 


自然 


”在 这 里 ,笔者 的 本 意 不 是 希望 纠正 外 界 对 于 Docker 容 器 的 认识 ， 而 是 希望 能 和 读者 一 起 来 看 看 Docker 容 器 技术 实现 的 原理 到 底 几何 。 


更 清楚 地 认识 Docker 容 器 之 后 ， 很 快 大 家 的 眼球 肯定 会 定位 到 namespaces 和 cgroups 这 两 种 技术 上 。Linux 内 核 的 这 两 种 技术 ， 


角度 简要 介绍 这 两 者 。 


首先 讲述 一 下 amespace 在 容器 创建 时 的 


法 。 


户 启动 容器 ，Docker Daemon 会 fork 出 容器 中 的 第 一 个 进程 A (暂且 称 为 进程 A， 也 就 是 Docker Daemon 
志 CLONE NEWNS, CLONE NEWUTS, CLONE NEWIPC, CLONE _PID 和 CLONE_NEWNET (Docker 1.2.0 还 没有 完全 支持 user namespace) 。Clone 系 统 调 
再 与 父 进 程 共享 相同 的 命名 空间 (namespaces) ， 而 是 由 Linux 为 子 进程 创建 新 的 命名 空间 (namespaces) ， 从 而 保证 子 进程 与 父 进程 使 


然 起 到 如 此 重大 的 作用 。 


。 对 此 ， 从 通俗 易 懂 的 角度 来 讲 ， 这 完全 可 以 理解 ， 因 为 “ 容 
Docker 创 建 一 个 进程 ， 为 这 个 进程 创建 隔离 的 环境 ， 这 样 的 环境 可 以 称 为 Docker 容 器 ， 然 后 再 在 容器 内 部 运行 用 户 应 用 进程 。 


我 们 就 从 Docker 容 器 实现 流程 的 


那么 下 


的 子 进程 ) ， 执 行 fork 


隔离 的 环境 。 另 外 ， 如 


果子 进程 A 再 次 forkH 


时 通过 5 个 参数 标 


且 传 入 了 这 些 参数 标志 ， 子 进程 将 不 


b 子 进程 B， 而 fork 


时 没有 传 入 相应 的 namespaces 参 数 标志 时 ， 子 进程 B 将 会 与 A 共 享 相同 的 命名 空间 (namespaces) 。 如 果 Docker Daemon 再 次 创建 一 个 Docker 容 器 ， 内 部 进程 有 D、E 和 F， 那 么 这 三 个 进程 也 会 处 于 另 


外 全 新 的 namespaces 中 。 两 个 容器 的 namespaces 均 与 Docker Daemon 所 在 的 namespaces 不 同 。Docker 中 Docker Daemon 与 Docker 容 器 之 间 的 namespaces 关 系 ， 如 医 


7-1 所 示 。 


namespace 


Docker 


fork with 
clone flags 


new namespace 


再 说 起 cgroups， 大 家 都 知道 可 以 使 用 cgroups 为 进程 组 做 资源 的 限制 。 与 namespaces 不 同 的 是 ，cgroup 的 使 


\ Daemon 


fork 
clone 


new namespace 
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with 
flags 


并 不 是 在 创建 容器 内 进程 时 完成 ， 而 是 在 创建 容器 内 进程 之 后 完成 ， 最 终 使 得 容器 进 


程 处 于 资源 控制 的 状态 。 换 言 之 ，cgroups 的 运用 必须 要 等 到 容器 内 第 一 个 进程 被 真正 创建 出 来 之 后 才能 实现 。 当 容器 内 进程 创建 完毕 ，Docker Daemon 可 以 获知 容器 内 主 进程 的 PID 信 息 ， 随 后 将 该 PID 


放置 在 cgroups 文 件 系 统 的 指定 位 置 ， 做 相应 的 资源 限制 。 如 此 一 来 ， 当 容器 主 进程 再 fork 新 的 子 进 程 时 ， 新 的 子 进程 同样 受到 与 主 进程 相同 的 资源 限制 ， 效 果 就 是 整个 进程 组 受到 资源 限制 。 


可 以 说 Linux 内 核 的 namespaces 和 cgroups 技 术 ， 实 现 了 资源 的 隔离 与 限制 。 那 么 对 于 资源 的 隔离 ， 是 否 还 需要 为 容器 准备 必需 的 资源 ， 比 如 说 容器 需要 使 
载 点 等 。 这 回答 案 是 肯定 的 。 网 络 资源 就 是 一 个 很 好 的 例子 。 当 Docker Daemon 为 进程 创建 完 隔离 的 运行 环境 之 后 ， 我 们 可 以 发 现 进程 并 没有 独立 的 网 络 栈 可 以 使 用 ， 如 独立 的 网 络 接口 等 。 此 


时 ，Docker Daemon 会 将 Docker 容 器 内 部 所 需要 的 资源 一 一 配备 齐全 。 网 络 方面 ， 即 为 Docker 容 器 通过 上 


本 章 从 源码 的 角度 ， 分 析 Docker 容 器 从 无 到 有 的 过 程 中 ，Docker 容 器 网 络 创 建 的 来 龙 去 脉 。 简 化 而 言 ， 


户 指定 的 网 络 模式 ， 配 置 相应 的 网 络 资源 。 


Docker 容 器 网 络 的 创建 流程 如 图 7-2 所 示 。 


的 网 络 资源 ， 容 器 需 


使 


的 文件 系统 挂 


Docker Client 


Docker Daemon 


networkdriver 


本 章 分 析 的 主要 内 容 有 以 下 5 部 分 : 


* Docker 容 器 的 网 络 模式 


* Docker Client 配 置 容器 网 络 


* Docker Daemon 创 建 容器 网 络 流程 


"execdtiver 网 络 执行 流程 


* libcontainer 实 现 内 核 态 网 络 配置 


execdriver 


libcontainer 


Docker Container 


图 7-2 ”Docker 容 器 网 络 创建 流程 图 


在 Docker 容 器 的 网 络 创建 过 程 中 ，networkdriver 模 块 使 用 并 非 是 重点 ， 故 分 析 内 容 中 不 涉及 networkdriver。 不 少 读者 肯定 会 有 一 些 疑 惑 ， 为 什么 Docker 容 器 的 网 络 创建 很 少 
里 强调 一 下 networkdriver 在 Docker 中 的 作用 : 第 一 ， 为 Docker Daemon 创 建 网 络 环境 的 时 候 ， 初 始 化 Docker Daemon 的 网 络 环境 ( 详 见 第 6 章 ) ， 比 如 创建 docker0 网 桥 等 ; 第 二 ， 为 Docker 容 器 分 配 


IP 地 址 ， 为 Docker 容 器 做 端口 映射 等 。 而 与 Docker 容 器 网 络 创建 有 关 的 


内 容 并 不 多 ， 如 只 在 桥接 模式 下 ， 为 Docker 容 器 的 网 络 接 


设备 分 配 一 个 IP 地 址 。 


到 networkdriver。 这 
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如 今 ，Docker 技 术 风 靡 全 球 ， 大 家 在 尝试 以 及 玩 转 Docker 的 同时 ， 肯 定 离 不 开 一 个 概念 ， 那 就 是 “容器 ”或 者 “Container”。 那 么 我 们 首先 从 原理 的 角度 一 帘 “ 容 器 ”或 者 “Container” 的 究竟 。 


第 一 次 接触 Docker 时 ， 大 家 肯定 会 深 深 感受 到 : 在 Docker 容 器 内 部 运行 应 用 程序 况 是 如 此 方便 。 第 一 ， 应 用 程序 在 Docker 容 器 内 部 的 部 署 与 运行 非常 便捷 ， 只 要 有 Dockerfile， 应 用 一 键 式 的 部 署 绝 
对 不 是 天 方 夜 谭 ; 第 二 ，Docker 容 器 内 运行 的 应 用 程序 还 可 以 受到 资源 的 控制 与 隔离 ， 大 大 满足 云 计 算 时 代 应 用 的 要 求 。 


毋 庸 置疑 ，Docker 的 一 些 特 性 ， 的 确 据 弃 了 传统 情况 下 开发 模式 的 不 少 浆 端 。 然 而 ， 这 强大 的 功能 背后 到 底 是 何等 技术 在 “ 作 崇 ”， 又 是 谁 可 以 支撑 Docker 的 运行 并 提供 丰富 的 特性 ?答案 很 简单 
那 就 Linux 内 核 。 


那 我 们 就 从 Linux 内 核 的 角度 来 看 看 Docker 到 | 底 为 何 物 ， 先 从 Docker 容 器 入 手 。 对 于 Docker 容 器 ， 体 验 过 的 开发 者 都 有 两 点 非常 重要 的 感受 : 内 部 可 以 跑 应 用 (进程 ) ， 以 及 提供 隔离 的 环境 。 当 然 ， 
后 者 肯定 也 是 工业 界 称 之 为 “容器 ”的 原因 之 一 。 


首先 ， 我 们 先 来 看 Docker 容 器 与 进程 的 关系 ， 或 者 容器 与 进程 的 关系 。 为 了 理 清 这 两 者 之 间 的 关系 ， 我 不 妨 提出 这 样 一 个 问题 “容器 是 否 可 以 脱离 进程 而 存在 ”。 换 名 话说 就 是 ， 能 否 创建 一 个 容器 ， 
而 这 个 容器 内 部 没有 任何 进程 。 答 案 是 否定 的 。 既 然 答案 是 否定 的 ， 说 明 不 可 能 先 有 容器 ， 然 后 再 有 进程 ， 那 么 问题 又 来 了 ，“ 容 器 和 进程 是 一 起 诞生 的 ， 还 是 先 有 进程 再 有 容器 呢 ? ”可 以 说 答案 是 后 
者 。 以 下 将 慢 慢 阐述 其 中 的 原因 。 


阐述 问题 “容器 是 否 可 以 脱离 进程 而 存在 ”的 原因 前 ， 相 信 大 家 对 于 下 面 这 段 话 不 会 有 异议 : 通过 Docker 创 建 出 的 一 个 Docker Container 是 一 个 容器 ， 而 这 个 容器 提供 了 进程 组 隔离 的 运行 环境 。 那 
么 问题 在 于 ， 容 器 到 底 是 通过 什么 途径 来 实现 进程 组 运行 环境 的 “隔离 ” 呢 ? 此 时 ， 就 轮 到 Linux 内 核 隆重 登场 了 。 


说 到 运行 环境 的 “隔离 ”， 相 信 大 家 肯定 对 Linux 内 核 中 的 namespaces 和 cgroups 略 有 耳闻 ，namespaces 主 要 负责 命名 空间 的 隔离 ，cgroups 主 要 负责 资源 使 用 的 限制 。 其 实 ， 正 是 这 两 个 神奇 的 内 
核 特性 联合 使 用 ， 才 保证 了 Docker 容 器 之 间 的 “隔离 ”。 那 么 ，namespaces 和 cgroups 又 和 进程 有 什么 关系 呢 ? 问题 的 答案 可 以 用 以 下 的 次 序 来 表示 : 


1) 父 进程 通过 fork 创 建 子 进 程 时 ， 使 用 namespaces 技 术 ， 实 现 子 进程 与 父 进程 以 及 其 他 进程 之 间 命 名 空间 的 隔离 。 


2) 子 进程 创建 完毕 之 后 ， 使 用 cgroups 技 术 来 处 理 进程 ， 实 现 进程 的 资源 限制 。 


3) namespaces 和 cgroups 这 两 种 技术 都 用 上 之 后 ， 进 程 所 处 的 “隔离 ”环境 才 真 正 建立 ， 此 时 “容器 ”真正 诞生 


从 Linux 内 核 的 角度 分 析 容 器 的 诞生 ， 精 简 的 流程 即 如 上 三 步 ， 而 这 三 个 步骤 也 恰好 巧妙 地 盖 述 了 namespaces 和 cgroups 这 两 种 技术 和 进程 的 关系 ， 以 及 进程 与 容器 的 关系 。 进 程 与 容器 的 关系 ， 自 然 
是 : 容器 不 能 脱离 进程 而 存在 ， 先 有 进程 ， 后 有 容器 。 然 而 ， 大 家 往往 会 说 到 “使 用 Docker 创 建 Docker 容 器 ， 然 后 在 容器 内 部 运行 进程 ”。 对 此 ， 从 通俗 易 懂 的 角度 来 讲 ， 这 完全 可 以 理解 ， 因 为 “ 容 
器 ”一 词 的 存在 ， 本 身 就 较为 抽象 。 如 果 需 要 更 为 准确 ， 可 以 表述 为 “使 用 Docker 创 建 一 个 进程 ， 为 这 个 进程 创建 隔离 的 环境 ， 这 样 的 环境 可 以 称 为 Docker 容 器 ， 然 后 再 在 容器 内 部 运行 用 户 应 用 进程 。 
”在 这 里 ， 笔 者 的 本 意 不 是 希望 纠正 外 界 对 于 Docker 容 器 的 认识 ， 而 是 希望 能 和 读者 一 起 来 看 看 Docker 容 器 技术 实现 的 原理 到 底 几 何 。 


更 清楚 地 认识 Docker 容 器 之 后 ， 很 快 大 家 的 眼球 肯定 会 定位 到 namespaces 和 cgroups 这 两 种 技术 上 。Linux 内 核 的 这 两 种 技术 ， 竟 然 起 到 如 此 重大 的 作用 。 那 么 下 面 我 们 就 从 Docker 容 器 实现 流程 的 
角度 简要 介绍 这 两 者 。 


首先 讲述 一 下 namespace 在 容器 创建 时 的 用 法 。 用 户 启动 容器 ，Docker Daemon 会 fork 出 容器 中 的 第 一 个 进程 A (暂且 称 为 进程 A， 也 就 是 Docker Daemon 的 子 进程 ) ， 执 行 fork 时 通过 5 个 参数 标 
志 CLONE_NEWNS、CLONE_NEWUTS、CLONE_NEWIPC、CLONE_PID 和 CLONE_NEWNET (Docker 1.2.0 还 没有 完全 支持 user namespace) 。Clone 系 统 调用 一 旦 传 入 了 这 些 参数 标志 ， 子 进程 将 不 
再 与 父 进程 共享 相同 的 命名 空间 (namespaces) ， 而 是 由 Linux 为 子 进程 创建 新 的 命名 空间 (namespaces) ， 从 而 保证 子 进程 与 父 进程 使 用 隔离 的 环境 。 另 外 ， 如 果子 进程 A 再 次 fork 出 子 进 程 B， 而 fork 
时 没有 传 入 相应 的 namespaces 参 数 标志 时 ， 子 进程 B 将 会 与 A 共 享 相同 的 命名 空间 (namespaces) 。 如 果 Docker Daemon 再 次 创建 一 个 Docker 容 器 ， 内 部 进程 有 D、E 和 F， 那 么 这 三 个 进程 也 会 处 于 另 
外 全 新 的 namespaces 中 。 两 个 容器 的 namespaces 均 与 Docker Daemon 所 在 的 namespaces 不 同 。Docker 中 Docker Daemon 与 Docker 容 器 之 间 的 namespaces 关 系 ， 如 图 7-1 所 示 。 
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再 说 起 cgroups， 大 家 都 知道 可 以 使 用 cgroups 为 进程 组 做 资源 的 限制 。 与 namespaces 不 同 的 是 ，cgroup 的 使 
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with 
flags 


并 不 是 在 创建 容器 内 进程 时 完成 ， 而 是 在 创建 容器 内 进程 之 后 完成 ， 最 终 使 得 容器 进 


程 处 于 资源 控制 的 状态 。 换 言 之 ，cgroups 的 运用 必须 要 等 到 容器 内 第 一 个 进程 被 真正 创建 出 来 之 后 才能 实现 。 当 容器 内 进程 创建 完毕 ，Docker Daemon 可 以 获知 容器 内 主 进程 的 PID 信 息 ， 随 后 将 该 PID 


放置 在 cgroups 文 件 系 统 的 指定 位 置 ， 做 相应 的 资源 限制 。 如 此 一 来 ， 当 容器 主 进程 再 fork 新 的 子 进 程 时 ， 新 的 子 进程 同样 受到 与 主 进程 相同 的 资源 限制 ， 效 果 就 是 整个 进程 组 受到 资源 限制 。 


可 以 说 Linux 内 核 的 namespaces 和 cgroups 技 术 ， 实 现 了 资源 的 隔离 与 限制 。 那 么 对 于 资源 的 隔离 ， 是 否 还 需要 为 容器 准备 必需 的 资源 ， 比 如 说 容器 需要 使 
载 点 等 。 这 回答 案 是 肯定 的 。 网 络 资源 就 是 一 个 很 好 的 例子 。 当 Docker Daemon 为 进程 创建 完 隔离 的 运行 环境 之 后 ， 我 们 可 以 发 现 进程 并 没有 独立 的 网 络 栈 可 以 使 用 ， 如 独立 的 网 络 接口 等 。 此 


时 ，Docker Daemon 会 将 Docker 容 器 内 部 所 需要 的 资源 一 一 配备 齐全 。 网 络 方面 ， 即 为 Docker 容 器 通过 上 


本 章 从 源码 的 角度 ， 分 析 Docker 容 器 从 无 到 有 的 过 程 中 ，Docker 容 器 网 络 创 建 的 来 龙 去 脉 。 简 化 而 言 ， 


户 指定 的 网 络 模式 ， 配 置 相应 的 网 络 资源 。 


Docker 容 器 网 络 的 创建 流程 如 图 7-2 所 示 。 


的 网 络 资源 ， 容 器 需 


使 


的 文件 系统 挂 


Docker Client 


Docker Daemon 


networkdriver 


本 章 分 析 的 主要 内 容 有 以 下 5 部 分 : 


* Docker 容 器 的 网 络 模式 


* Docker Client 配 置 容器 网 络 


* Docker Daemon 创 建 容器 网 络 流程 


"execdtiver 网 络 执行 流程 


* libcontainer 实 现 内 核 态 网 络 配置 


execdriver 


libcontainer 


Docker Container 


图 7-2 ”Docker 容 器 网 络 创建 流程 图 


在 Docker 容 器 的 网 络 创建 过 程 中 ，networkdriver 模 块 使 用 并 非 是 重点 ， 故 分 析 内 容 中 不 涉及 networkdriver。 不 少 读者 肯定 会 有 一 些 疑 惑 ， 为 什么 Docker 容 器 的 网 络 创建 很 少 
里 强调 一 下 networkdriver 在 Docker 中 的 作用 : 第 一 ， 为 Docker Daemon 创 建 网 络 环境 的 时 候 ， 初 始 化 Docker Daemon 的 网 络 环境 ( 详 见 第 6 章 ) ， 比 如 创建 docker0 网 桥 等 ; 第 二 ， 为 Docker 容 器 分 配 


IP 地 址 ， 为 Docker 容 器 做 端口 映射 等 。 而 与 Docker 容 器 网 络 创建 有 关 的 


内 容 并 不 多 ， 如 只 在 桥接 模式 下 ， 为 Docker 容 器 的 网 络 接 


设备 分 配 一 个 IP 地 址 。 


到 networkdriver。 这 


7.2 ”Docker 容 器 网 络 模式 


如 前 所 述 ，Docker 可 以 为 容器 创建 隔离 的 网 络 环境 ， 在 隔离 的 网 络 环境 下 ，Docker 容 器 使 用 独立 的 网 络 栈 。 看 到 这 ， 很 多 读者 也 许 会 非常 赞成 以 上 的 言论 。 然 而 ，Docker 容 器 网 络 的 高 级 特性 又 会 让 


爱好 者 们 感受 到 其 中 暗藏 的 更 多 玄机 。 


直 奔 主题 ， 其 实 Docker 除 可 以 为 Docker 容 器 创建 隔离 的 网 络 环境 之 外 ， 同 样 有 能 力 为 Docker 容 器 创建 共享 的 网 络 环境 。 换 言 之 ， 当 开发 者 需要 Docker 容 器 与 宿主 机 或 者 : 


其 他 容器 网 络 隔离 ，Docker 


可 以 满足 这 样 的 需求 ; 当 开 发 者 需要 Docker 容 器 的 网 络 处 于 共享 的 网 络 环境 时 ，Docker 同 样 可 以 满足 这 样 的 需求 ， 并 且 网 络 共享 ， 可 以 是 Docker 容 器 与 宿 3 


容器 之 间 网 络 共享 。 神 奇 的 是 ，Docker 还 可 以 实现 不 为 Docker 容 器 创建 网 络 环境 。 


通过 以 上 描述 ， 可 以 总 结 出 Docker 容 器 共有 以 下 4 种 网 络 模式 : bridge 桥 接 模 式 、host 模 式 、other container 模 式 和 none 模 式 。 下 面 分 别 介绍 Docker 的 4 种 网 络 模式 。 


7.3 Docker Client 配 置 容器 网 络 模式 


Docker 容 器 网 络 模式 的 多 样 性 ， 极 大 地 满足 了 Docker 用 户 部 署 应 用 的 网 络 需求 。Docker 用 户 ， 或 者 基于 Docker 的 二 次 开发 者 ， 均 可 以 在 这 基础 上 ， 选 择 使 用 与 


从 


IR] 


求 ， 选 择 网 络 模式 ， 并 将 其 通过 Docker Client 传 递 给 Docker Daemon。 本 小 节 将 从 Docker Client 源 码 的 角度 出 发 ， 分 析 如 何 通过 参数 的 形式 配置 Docker 容 器 的 
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FE 机 之 间 网 络 共享 ， 也 可 以 是 Docker 容 器 与 其 他 


身 应 


最 为 贴切 的 网 络 模式 。 


7-2 中 可 以 看 到 ，Docker 容 器 网 络 创建 流程 中 第 一 个 涉及 的 Docker 模 块 就 是 Docker Client。 当 然 ， 这 也 容易 理解 ， 毕 竟 Docker 容 器 网 络 环境 的 创建 需要 由 


户 发 起 。 
网 络 模式 ， 以 及 Docker Client 内 部 如 何 处 


户 根据 自身 对 容器 的 需 


Docker Daemon 接 收 到 Docker Client 的 请 求 可 以 分 为 两 次 ， 第 一 次 为 create container， 第 二 次 为 start container。 这 两 次 请 求 的 执行 过 程 ， 都 与 Docker 容 器 的 网 络 相关 。 以 下 按照 这 两 个 请 求 的 执 


行 , 具 


7.5 ”execdriver 网 络 执行 流程 


具体 分 析 Docker 容 器 网 络 的 创建 。Docker Daemon 如 何 通 过 Docker Server 解 析 RESTful 请 求 ， 并 完成 路 由 ， 在 第 5 章 已 经 详细 分 析 过 ， 故 本 章 不 再 歼 述 。 


Docker 架 构 中 execdriver 的 作用 是 启动 容器 内 部 进程 ， 最 终 启动 容器 。 目 前 ， 在 Docker 中 execdriver 作 为 执行 驱动 ， 可 以 有 两 种 选项 : |xc 与 native。 其 中 ，|xc 驱 动 会 调用 |xc 工 具 实现 容器 的 启动 ， 而 


native 驱 动 会 使 用 Docker 官 方 发 布 的 libcontainer 来 启动 容器 。 


Docker Daemon 启 动 过 程 中 ，execdriver 的 类 型 默认 为 native， 故 本 章 主要 分 析 native 驱 动 在 执行 启动 容器 时 ， 如 何 处 理 网 络 部 分 。 


在 Docker Daemon 启 动容 器 的 最 后 一 步 ， 即 调用 了 execdriver 的 Run 函 数 来 执行 。 通 过 分 析 Run 函 数 的 
1) 创建 libcontainer 的 Config 对 象 。 


2) 通过 libcontainer 中 的 namespaces 包 执行 启动 容器 。 


将 execdriver.Run 函 数 的 运行 流程 展开 ， 与 Docker 容 器 网 络 相关 的 流程 ， 如 图 7-8 所 示 。 


人 体 实 现 ， 可 知 关于 Docker 容 器 的 网 络 执 : 


行 流程 


EF 要 包括 两 个 环节 : 


create. go 


template. New () 


driver. go 创建 1ibcontainer. Confi g 异 板 


createContainer 


创建 libcontainer. Config 对 象 


v 


daemon. go 


execdriver. Run 
BU 


Docker Daemon 启 动容 器 


createNetwork 


创建 具体 网 络 环境 的 配置 


| 
| 
| 
| 
| 


. 


namespaces. Exec 


execdriver 启 动容 器 


7-8 ”execdtiver.Run 执 行 流程 图 


7.6 libcontainer 实 现 内 核 态 网 络 配置 


libcontainer 是 一 个 Linux 操 作 系统 上 容器 技术 的 解决 方案 。libcontainer 指 定 了 创建 一 个 容器 时 所 需要 的 配置 选项 ， 同 时 它 利 用 Linux 中 namespaces 和 cgroups 等 技术 为 使 用 者 提供 了 一 套 Golang 原 生 
态 的 容器 实现 方案 ， 并 且 没 有 使 用 任何 外 部 依赖 。 借助 libcontainer， 可 以 感受 到 众多 操作 命名 空间 、 网 络 等 资源 的 便利 。 


当 execdriver 调 用 libcontainer 中 namespaces 包 的 Exec 函 数 时 ，libcontainer 开 始 发 挥 其 实现 容器 功能 的 作用 。Exec 函 数位 于 ./dockerlibcontainenamespaces/exec.go#L24-L113。 本 节 更 多 地 关 
心 Docker 容 器 的 网 络 创建 ， 因 此 从 这 个 角度 来 看 Exec 的 实现 可 以 分 为 三 个 步骤 : 


1) 通过 createCommand 创 建 一 个 Golang 语 言 内 的 exec.Cmd 对 象 。 
2) 启动 命令 exec.Cmd， 创建 容 器 内 的 第 一 个 进程 。 


3) 通过 InitializeNetworking 函 数 为 容器 进程 初始 化 网 络 环境 。 


以 下 从 源码 实现 的 角度 ， 详 细 分 析 这 三 个 部 分 。 


7.7 总 结 


如 何 使 用 Docker 容 器 的 网 络 ， 一 直 是 工业 界 关 心 的 问题 。 本 章 从 Linux 内 核 原理 的 角度 阐述 了 什么 是 Docker 容 器 ， 并 对 Docker 容 器 的 4 种 网 络 模式 进行 了 初步 的 介绍 ， 最 终 贯穿 Docker 架 构 中 的 多 个 模 
块 ， 如 Docker Client, Docker Daemon、execdriver 以 及 libcontainer， 深 入 分 析 了 Docker 容 器 网 络 的 实现 。 


目前 ， 若 只 谈论 Docker， 那 么 它 还 是 只 停留 在 单 宿 主机 的 场景 上 。 如 何 面 对 跨 宿主 机 的 场景 、 如 何 实 现 分 布 式 Docker 容 器 的 管理 ， 目 前 为 止 还 没有 一 个 一 劳 永 逸 的 解决 方案 。 再 者 ， 一 个 解决 方案 的 
存在 ， 总 是 会 适应 于 一 个 应 用 场景 。Docker 这 种 容器 技术 的 发 展 ， 大 大 改善 了 传统 模式 下 使 用 诸如 虚拟 机 等 传统 计算 单位 存在 的 多 种 弊端 ， 却 在 网 络 方面 使 得 自身 的 使 用 存在 瑕 症 。 希 望 本 章 是 一 个 引子 ， 
介绍 Docker 容 器 网 络 ， 从 源码 的 角度 分 析 Docker 容 器 网 络 之 后 ， 能 使 更 多 的 Docker 爱 好 者 思考 Docker 容 器 网 络 的 来 龙 去 脉 ， 并 为 Docker 乃 至 容器 技术 的 发 展 做 出 贡献 。 


m 


第 8 章 ”Docker 镜 像 


8.1 引言 


2014 年 ，Docker 便 在 全 球 刊 起 了 一 阵 又 一 阵 的 “容器 风 ”， 全 球 的 开发 者 开始 认识 Docker， 学 习 Docker。 又 过 了 一 年 ， 工 业界 对 Docker 的 态度 已 经 不 再 是 了 解 与 观望 ， 转 而 是 实践 一 波 高 过 一 波 。 
Docker 目 前 的 发 展 似乎 并 不 会 像 其 他 屋 花 一 现 的 技术 一 样 ， 反 而 是 凭借 创新 性 的 特性 ，Docker 在 工业 界 经 过 实践 与 评估 之 后 ， 显 现 了 前 所 未 有 的 潜力 。 


究 其 本 质 ，“Docker 提 供 容器 服务 ”这 句 话 ， 相 信 很 少 有 人 会 有 异议 。 既 然 如 此 ，Docker 提 供 的 服务 属于 “容器 ”技术 ， 那 么 反观 “容器 ”技术 的 本 质 与 发 展 历史 ， 我 们 又 可 以 发 现 什 么 呢 ? 正如 第 7 
章 所 提 到 的 ，Docker 使 用 的 “容器 ”技术 ， 主 要 是 以 Linux 内 核 的 namespace、cgroup 等 特性 为 基础 ， 保 障 进程 或 者 进程 组 处 于 一 个 隔离 、 受 限 、 安 全 的 环境 之 中 。Docker 第 一 个 版 本 在 2013 年 3 月 发 
行 ， 而 cgroups 正 式 在 Linux 操 作 系统 中 的 亮相 可 以 追溯 到 2007 年 下 半年 ， 当 时 cgroups 被 合并 至 Linux 内 核 2.6.24 版 本 。 这 整整 年 时 间 并 不 是 Linux 平 台 “ 容 器 ”技术 发 展 的 真空 期 。2008 年 LXC (Linux 


Container) 诞生 ， 它 简化 了 容器 的 创建 与 管理 ;之 后 业界 一 些 Paas 平 台 也 初步 尝试 采用 容器 技术 作为 其 云 应 用 的 运行 环境 。 而 在 Docker 发 布 的 同年 ，Google 也 发 布 了 开源 容器 管理 工具 Imctfy。 除 此 之 
外 ， 若 抛 开 Linux 操 作 系统 ， 其 他 操作 系统 (如 FreeBSD、Solaris 等 ) 同样 诞生 了 作用 类 似 的 “容器 ”技术 ， 其 发 展 历史 更 是 可 以 追溯 至 干 禧 年 初期 。 


总 之 ，“ 容 器 ”技术 的 发 展 不 可 谓 短暂 ， 然 而 论 同时 代 的 影响 力 ， 却 鲜 有 Docker 的 媲美 者 。 不 论 是 云 计算 大 潮 催生 了 Docker 技 术 ， 抑 或 是 Docker 技 术 赶 上 了 云 计 算 的 大 时 代 ， 姓 庸 置疑 的 是 ，Docker 
作为 技术 领域 的 新 宠儿 ， 必 将 继续 受到 业界 的 广泛 青睐 。 云 计算 时 代 ， 分 布 式 应 用 逐渐 流行 ， 大 部 分 应 用 对 自身 的 构建 、 交 付 与 运行 都 有 着 与 传统 不 一 样 的 需求 。 借 助 Linux 内 核 的 namespace 和 cgroup 等 
特性 ， 自 然 可 以 实现 应 用 运行 环境 的 资源 隔离 与 限制 等 ; 然而 ，namespace 和 cgroup 等 内 核 特 性 却 无 法 为 容器 的 运行 环境 做 全 盘 打 包 。 而 Docker 的 设计 则 非常 巧妙 地 考虑 到 了 这 一 点 ， 除 namespace 和 
cgroup 之 外 ，Docker 另 外 采用 了 神奇 的 “镜像 ”技术 作为 Docker 管 理 文件 系统 以 及 运行 环境 强 有 力 的 补充 。Docker 灵 活 的 “镜像 ”技术 ， 在 笔者 看 来 ， 也 是 其 大 红 大 紫 最 重要 的 因素 之 一 。 
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81 引言 


2014 年 ，Docker 便 在 全 球 乔 起 了 一 阵 又 一 阵 的 “容器 风 ”， 全 球 的 开发 者 开始 认识 Docker， 学 习 Docker。 又 过 了 一 年 ， 工 业界 对 Docker 的 态度 已 经 不 再 是 了 解 与 观望 ， 转 而 是 实践 一 波 高 过 一 波 。 
Docker 目 前 的 发 展 似乎 并 不 会 像 其 他 县 花 一 现 的 技术 一 样 ， 反 而 是 凭借 创新 性 的 特性 ，Docker 在 工业 界 经 过 实践 与 评估 之 后 ， 显 现 了 前 所 未 有 的 潜力 。 


究 其 本 质 ，“Docker 提 供 容器 服务 ”这 句 话 ， 相 信 很 少 有 人 会 有 异议 。 既 然 如 此 ，Docker 提 供 的 服务 属于 “容器 ”技术 ， 那 么 反观 “容器 ”技术 的 本 质 与 发 展 历史 ， 我 们 又 可 以 发 现 什么 呢 ? 正 如 第 7 
章 所 提 到 的 ，Docker 使 用 的 “容器 ”技术 ， 主 要 是 以 Linux 内 核 的 Namespace、cgroup 等 特性 为 基础 ， 保 障 进程 或 者 进程 组 处 于 一 个 隔离 、 受 限 、 安 全 的 环境 之 中 。Docker 第 一 个 版 本 在 2013 年 3 月 发 
行 ， 而 cgroups 正 式 在 Linux 操 作 系 统 中 的 亮相 可 以 追溯 到 2007 年 下 半年 ， 当 时 cgroups 被 合并 至 Linux 内 核 2.6.24 版 本 。 这 整整 6 年 时 间 并 不 是 Linux 平 台 “ 容 器 ”技术 发 展 的 真空 期 。2008 年 LXC (Linux 
Container) 诞生 ， 它 简化 了 容器 的 创建 与 管理 ; 之 后 业界 一 些 PaaS 平 台 也 初步 尝试 采用 容器 技术 作为 其 云 应 用 的 运行 环境 。 而 在 Docker 发 布 的 同年 ，Google 也 发 布 了 开源 容器 管理 工具 Imctfy。 除 此 之 
外 ， 若 抛 开 Linux 操 作 系统 ， 其 他 操作 系统 (如 FreeBSD、Solaris 等 ) 同样 诞生 了 作用 类 似 的 “容器 ”技术 ， 其 发 展 历史 更 是 可 以 追溯 至 干 禧 年 初期 。 


总 之 ，“ 容 器 ”技术 的 发 展 不 可 谓 短暂 ， 然 而 论 同 时 代 的 影响 力 ， 却 鲜 有 Docker 的 媳 美 者 。 不 论 是 云 计 算 大 潮 催生 了 Docker 技 术 ， 抑 或 是 Docker 技 术 赶 上 了 云 计算 的 大 时 代 ， 毋 庸 置疑 的 是 ，Docker 
作为 技术 领域 的 新 宠儿 ， 必 将 继续 受到 业界 的 广泛 青睐 。 云 计算 时 代 ， 分 布 式 应 用 逐渐 流行 ， 大 部 分 应 用 对 自身 的 构建 、 交 付 与 运行 都 有 着 与 传统 不 一 样 的 需求 。 借 助 Linux 内 核 的 namespace 和 cgroup 等 
特性 ， 自 然 可 以 实现 应 用 运行 环境 的 资源 隔离 与 限制 等 ; 然而 ，namespace 和 cgroup 等 内 核 特 性 却 无 法 为 容器 的 运行 环境 做 全 盘 打 包 。 而 Docker 的 设计 则 非常 巧妙 地 考虑 到 了 这 一 点 ， 除 namespace 和 
cgroup 之 外 ，Docker 另 外 采用 了 神奇 的 “镜像 ”技术 作为 Docker 管 理 文件 系统 以 及 运行 环境 强 有 力 的 补充 。Docker 灵 活 的 “镜像 ”技术 ， 在 笔者 看 来 ， 也 是 其 大 红 大 紫 最 重要 的 因素 之 一 。 
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Docker 诞 生 至 今 ， 很 多 容器 领域 从 业者 都 会 将 Docker 技 术 与 虚拟 机 技术 相提并论 。 提 及 Docker 镜 像 ， 大 家 肯定 也 会 联想 到 虚拟 机 中 的 镜像 。 镜 像 是 一 种 文件 存储 形式 ， 文 件 管理 员 可 以 通过 技术 手段 
将 很 多 文件 制作 成 一 个 镜像 。 对 于 虚拟 机 而 言 ， 镜 像 文件 中 存储 着 操作 系统 、 文 件 系统 内 容 、 设 备 文件 等 。 可 以 说，Docker 镜 像 与 虚拟 机 镜像 有 很 大 的 相似 度 ， 然 而 也 有 着 本 质 的 区 别 。 相 似 的 是 ， 两 者 存 
储 内 容 大 致 相同 ， 都 会 含有 文件 系统 内 容 ; 不 同 的 是 ，Docker 镜 像 不 含 操作 系统 内 容 ， 同 时 Docker 镜 像 由 多 个 镜像 组 成 。 


根据 Docker 官 方 网 站 上 的 技术 文档 描述 ，image (镜像 ) 是 Docker 术 语 的 一 种 ， 对 于 容器 而 言 ， 它 代表 一 个 只 读 的 layer。 而 layer 则 具体 代表 Docker 容 器 文件 系统 中 可 翅 加 的 一 部 分 。 


如 此 介绍 Docker 镜 像 ， 相 信众 多 Docker 爱 好 者 理解 起 来 仍然 是 云 里 雾 里 。 那 么 理解 之 前 ， 先 让 我 们 来 认识 一 下 与 Docker 镜 像 相 关 的 4 个 概念 : rootfs, union mount、image 以 及 layer。 


8.3 rootfs 


rootfs 代 表 一 个 Docker 容 器 在 启动 时 (而 非 运行 后 ) 其 内 部 进程 可 见 的 文件 系统 视角 ， 或 者 Docker 容 器 的 根 目录 。 当 然 ， 该 目录 下 含有 Docker 容 器 所 需要 的 系统 文件 、 工 具 、 容 器 文件 等 。 


传统 上 ，Linux 操 作 系 统 内 核 启动 时 ， 内 核 首先 会 挂 载 一 个 只 读 (read-only) 的 rootfs， 当 系统 检测 其 完整 性 之 后 ， 决 定 是否 将 其 切换 为 读 写 (read-write) 模式 ， 或 者 最 后 在 rootfs 之 上 另行 挂 载 一 种 
文件 系统 并 忽略 rootfs。Docker 架 构 下 ， 依 然 沿用 Linux 中 rootfs 的 思想 。 当 Docker Daemon 为 Docker 容 器 挂 载 rootfs 的 时 候 ， 与 传统 Linux 内 核 类 似 ， 将 其 设 定 为 只 读 模 式 。 在 rootfs 挂 载 完 毕 之 后 ， 和 
Linux 内 核 不 一 样 的 是 ，Docker Daemon 没 有 将 Docker 容 器 的 文件 系统 设 为 读 写 模 式 ， 而 是 利用 Union Mount 的 技术 ， 在 这 个 只 读 的 rootfs 之 上 再 挂 载 一 个 读 写 的 文件 系统 ， 挂 载 时 该 读 写 文件 系统 内 空 
无 一 物 。 在 这 里 ， 我 们 暂且 把 Docker 容 器 的 文件 系统 这 么 理解 : 只 含 只 读 的 rootfs 和 可 读 写 的 文件 系统 。 


举 一 个 Ubuntu 容 器 启动 的 例子 。 假 设 用 户 已 经 通过 Docker Registry 下 拉 了 Ubuntu: 14.04 的 镜像 ， 并 通过 命令 docker run-it ubuntu: 14.04/bin/bash 将 其 启动 并 运行 ， 则 Docker Daemon 为 其 创 
建 的 rootfs 以 及 容器 可 读 写 的 文件 系统 如 图 8-1 所 示 。 


/bin /dev /home /lib64 /mnt /proc 


/srv /tmp /var /boot /lib /etc (H E IFRA) 
E N, ^ PIN 


/media /opt /root /sbin /sys / ( rootfs ) 


图 8-1 Ubuntu 14.04 容 器 文件 系统 示意 图 


顾名思义 ， 该 容器 中 的 进程 对 rootfs 中 的 内 容 只 拥有 读 权限 ， 对 于 读 写 文件 系统 中 的 内 容 既 拥有 读 权限 也 拥有 写 权 限 。 通 过 观察 图 8-1 可 以 发 现 : 容器 虽然 只 有 一 个 文件 系统 ， 但 该 文件 系统 由 “两 


”组 成 ， 分 别 为 读 写 文件 系统 和 只 读 文件 系统 。 通 过 这 样 的 理解 ， 文 件 系统 已 然 有 了 层级 (layer) 的 意味 。 


简单 来 讲 ， 可 以 将 Docker 容 器 的 文件 系统 分 为 两 部 分 ， 而 前 面 提 到 的 Docker Daemon 利 用 Union Mount 技 术 ， 将 两 者 挂 载 。 那 么 Union Mount 又 是 一 种 怎样 的 技术 ? 下 一 节 将 介绍 Union Mount 的 


p 


8.4 Union Mount 


Union Mount RPR RAERD, OFEA RARER, HARRI, SESUESRISCUERRASUI ES STTEIRBS RR. 


一 般 情况 下 ， 若 通过 某 种 文件 系统 挂 载 内容 至 挂 载 点 ， 挂 载 点 目录 中 原先 的 内 容 将 会 被 隐藏 。 而 Union Mount 则 不 会 将 挂 载 点 目录 中 的 内 容 隐藏 ， 反 而 是 将 挂 载 点 目录 中 的 内 容 和 被 挂 载 的 内 容 合并 ， 


并 为 合并 后 的 内 容 提供 一 个 统一 独立 的 文件 系统 视角 。 通 常 来 讲 ， 被 合并 的 文件 系统 中 只 有 一 个 会 以 读 写 (read-write) 模式 挂 载 ， 其 他 文件 系统 的 挂 载 模式 均 为 只 读 (read-only) 。 实 现 这 种 Union 
Mount 技 术 的 文件 系统 一 般 称 为 联合 文件 系统 (Union Filesystem) ， 较 为 常见 的 有 UnionFS、aufs、OverlayFS 等 。 


Docker 实 现 容器 文件 系统 Union Mount 时 ， 提 供 多 种 具体 的 文件 系统 解决 方案 ， 如 Docker 早 期 版 本 沿用 至 今 的 AUFS， 还 有 在 Docker 1.4.0 版 本 中 开始 支持 的 OverlayFS 等 。 


为 了 更 深入 地 了 解 Union Mount， 可 以 使 用 aufs 文 件 系统 来 进一步 阐述 本 章 前 面 Ubuntu : 14.04 容 器 文件 系统 的 例子 ， 挂 载 Ubuntu 14.04 文 件 系统 的 示意 图 如 图 8-2 所 示 。 


使 用 镜像 Ubuntu: 14.04 创 建 的 容器 中 ， 可 以 暂且 将 该 容器 的 整个 rootfs 当 成 一 个 文件 系统 。 前 面 也 提 到 ， 挂 载 时 读 写 文件 系统 中 空 无 一 物 。 既 然 如 此 ， 从 用 户 视角 来 看 ， 容 器 内 文件 系统 和 rootfs 完 


一 样 ， 用 户 完全 可 以 按照 往常 习惯 ， 无 差别 地 使 用 自身 视角 下 文件 系统 中 的 所 有 内 容 ; 然而 ， 从 内 核 的 角度 来 看 ， 两 者 有 非常 大 的 区 别 。 追 溯 区 别 存在 的 根本 原因 ， 那 就 不 得 不 提 及 aufs 等 文件 系统 的 


COW (copy-on-write) 特性 。 


rootfs 


读 写 文件 系统 


bin /dev home lib64 /mnt  /proc 


srv tmp var boot lib etc 


/media /opt root /sbin 


Union Mount ( aufs) 


bin /dev /home /lib64 /mnt proc 


用 户 视 角 /srv /tmp /var /boot lib /etc 


^media 'opt root 'sbin 


内 核 视角 | /bin /dev /home /lib64 /mnt /proc 
/srv /tmp /var /boot /lib /etc — : 
(只 读 文 件 系 统 ) 


/media /opt /root /sbin /sys /usr 


(rootfs) 


图 8-2 aufs 挂 载 Ubuntu 14.04 文 件 系统 的 示意 区 


COW/ 文 件 系统 和 其 他 文件 系统 最 大 的 区 别 就 是 : 前 者 从 不 覆 写 已 有 文件 系统 中 已 有 的 内 容 。 通 过 COW 文 件 系统 将 两 个 文件 系统 (rootfs 和 读 写 文 件 系统 ) 合并 ， 最 终 用 户 视角 为 合并 后 含有 所 有 内 容 


的 文件 系统 ， 然 而 在 Linux 内 核 逻 辑 上 依然 可 以 区 别 两 者 ， 那 就 是 用 户 对 原先 rootfs 中 的 内 容 拥有 只 读 权 限 ， 而 对 读 写 文件 系统 中 的 内 容 拥有 读 写 权限 。 


既然 对 用 户 而 言 ， 全 然 不 知 哪些 内 容 只 读 ， 哪 些 内 容 可 读 写 ， 这 些 信息 只 有 内 核 在 接管 ， 那 么 假设 用 户 需 要 更 新 其 视角 下 的 文件 /etc/bash.bashrc， 而 该 文件 又 恰巧 是 rootfs 只 读 文件 系统 中 的 内 容 ， 


内 核 是 否 会 抽出 异常 或 者 驳回 用 户 请 求 呢 ? 答案 是 否定 的 。 当 此 情形 发 生 时 ，COW 文 件 系统 首先 不 会 覆 写 只 读 文 件 系统 中 的 文件 ， 即 不 会 覆 写 rootfs 中 的 /etc/bash.bashrc， 其 次 反而 会 将 该 文件 复制 至 读 
写 文件 系统 中 ， 即 将 /etc/bash.bashrc 复 制 至 读 写 文件 系统 中 的 /etc/bash.bashrc (此 时 ，rootfs 文 件 系统 和 读 写 文 件 系统 中 各 含有 一 份 /etc/bash.bashrc) ， 最 后 再 对 后 者 进行 更 新 操作 。 如 此 一 来 ， 纵 使 
rootfs 与 读 写 文件 系统 中 均 有 /etc/bash.bashrc， 诸 如 aufs 类 型 的 COW 文 件 系统 也 能 保证 用 户 视角 中 只 能 看 到 读 写 文件 系统 中 的 /etc/bash.bashrc， 即 更 新 后 的 内 容 。 


时 


当然 ， 这 样 的 特性 同样 支持 rootfs 中 文件 的 删除 等 其 他 操作 。 例 如 : 用 户 通过 apt-get 软 件 包 管 理工 具 安 装 Golang， 所 有 与 Golang 相 关 的 内 容 都 会 安装 在 读 写 文件 系统 中 ， 而 不 会 安装 在 rootfs 中 。 此 


户 又 希望 通过 apt-get 软 件 包 管 理工 具 删除 所有 关于 MySQL 的 内 容 ， 恰 巧 这 部 分 内 容 又 都 存在 于 rootfs 中 ， 删 除 操作 执行 时 同样 不 会 删除 rootfs 实 际 存在 的 MySQL， 而 是 在 读 写 文件 系统 中 删除 该 部 分 


内 容 ， 导 致 最 终 rootfs 中 的 MySQL 对 容器 用 户 不 可 见 ， 也 不 可 访 。 由 于 读 写 文件 系统 中 根本 不 存在 MySQL 的 相关 内 容 ， 因 此 似乎 在 读 写 文件 系统 中 找 不 到 需要 删除 的 对 象 。 此 时 ，aufs 保 障 在 读 写 文件 系统 
中 对 这 些 文件 内 容 做 相关 的 标记 (whiteout) ， 确 保 用 户 在 查看 文件 系统 内 容 时 ， 读 写 文件 系统 中 的 whiteout 将 遮盖 住 rootfs 中 的 相应 内 容 ， 导 致 这 些 内 容 不 可 见 ， 以 达到 与 删除 这 部 分 内 容 相 类 似 的 效 


FR. 


掌握 Docker 中 rootfs 以 及 Union Mount 的 概念 之 后 ， 再 来 理解 Docker 镜 像 ， 就 会 有 水 到 渠 成 的 感觉 。 


8.5 image 


Docker 中 rootfs 的 概念 ， 起 到 容器 文件 系统 中 基石 的 作用 。 对 于 容器 而 言 ， 其 只 读 的 特性 也 是 不 难 理解 。 神 奇 的 是 ， 实 际 情况 下 Docker 架 构 中 rootfs 的 设计 与 实现 比 前 面 的 描述 还 要 精妙 得 多 。 


继续 以 Ubuntu 14.04 为 例 ， 昌 然 通过 aufs 可 以 实现 rootfs 与 读 写 文件 系统 的 合并 ， 但 是 考虑 到 rootfs 自 身 接近 200MB 的 磁盘 大 小 ， 如 果 以 这 个 rootfs 的 粒度 来 实现 容器 的 创建 与 迁移 等 ， 是 否 会 稍 显 笨 
重 ” 同 时 也 会 大 大 降低 镜像 的 灵活 性 ”而 且 ， 若 用 户 希 望 拥有 一 个 Ubuntu 14.10 的 rootfs， 那 么 是 否 有 必要 创建 一 个 全 新 的 rootfs， 毕 竟 Ubuntu 14.10 和 Ubuntu 14.04 的 rootfs 中 有 很 多 一 致 的 内 容 。 


Docker 中 image 的 概念 ， 非 常 巧 妙 地 解决 了 以 上 问题 。 最 为 简单 地 解释 image， 它 就 是 Docker 容 器 中 只 读 文件 系统 rootfs 的 一 部 分 。 换 言 之 ， 实 际 上 Docker 容 器 的 rootfs 可 以 由 多 个 image 来 构成 。 多 
个 image 构 成 rootfs 的 方式 依然 沿用 Union Mount 技 术 。 


多 个 image 构 成 的 rootfs 如 图 8-3 所 示 (其 中 ，rootfs 中 每 一 层 image 中 的 内 容 划 分 只 为 了 阐述 清楚 rootfs 由 多 个 image 构 成 ， 并 不 代表 实际 情况 下 rootfs 中 的 内 容 划 分 ) : 


读 写 文件 系统 
/lib /etc imageID 3 

/media /opt /home imageID 2 

(多 个 镜像 ) /bin /dev  /usr /lib64 imageID 1 


/srv /tmp /var /boot /proc /sys /sbin =+ imagelD 0 


图 8-3 ”容器 rootfs 多 image 构 成 图 


从 图 8-3 中 我 们 可 以 看 出 ， 容 器 rootfs 包 含 4 个 image， 其 中 每 个 image 中 都 有 一 些 用户 视 角 文 件 系统 中 的 一 部 分 内 容 。4 个 image 处 于 层 亚 的 关系 ， 除 了 最 底层 的 image， 每 一 层 的 image 都 到 加 在 另 一 
个 image 之 上 。 另 外 ， 每 一 个 image 均 含有 一 个 image ID， 用 于 唯一 地 标记 该 image。 


基于 以 上 概念 ，Docker Image 中 又 抽象 出 两 种 概念 : 父 镜像 以 及 基础 镜像 。 除 了 容器 rootfs 最 底层 的 镜像 ， 其 余 镜像 都 依赖 于 其 底下 的 一 个 或 多 个 镜像 。 这 种 情况 下 ，Docker 将 下 一 层 的 镜像 称 为 上 
一 层 镜像 的 父 镜像 。 以 图 9-3 为 例 ，imagelD_0 是 imagelD 1 的 父 镜像 ，imagelD 2 是 imagelD 3 的 父 镜 像 ， 而 imagelD_0 没 有 父 镜像 。 对 于 最 下 层 的 镜像 ， 即 没有 父 镜像 的 镜像 ， 在 Docker 中 我 们 习惯 称 
之 为 基础 镜像 。 


通过 image 的 形式 ， 原 先 较为 腾 肿 的 rootfs 被 逐渐 打 散 成 轻便 的 多 层 。 除 了 轻便 的 特性 之 外 ，image 同 时 还 有 前 面 提 到 的 只 读 特性 ， 如 此 一 来 ， 在 不 同 的 容器 、 不 同 的 rootfs 中 image 完 全 可 以 用 来 复 


多 image 组 织 关系 与 复 用 关系 如 图 8-4 所 示 (图 中 镜像 名 称 的 举例 只 为 将 image 之 间 的 关系 阐述 清楚 ， 并 不 代表 实际 情况 下 相应 名 称 image 之 间 的 关系 ) : 


imagelD 3 


imagelD 8 imagelD 10 


imagelD 2 imagelD 4 imagelD 7 


imagelD 1 imagelD 6 imagelD 9 


imageID 0 imageID 5 


图 8-4 ”多 image 组 织 关 系 示意 图 


图 8-4 中 ， 共 罗列 了 11 个 image， 这 11 个 image 之 间 的 关系 呈现 为 一 幅 森 林 图 。 和 森林 中 含有 两 棵 树 ， 左 边 树 中 包含 5 个 节点 ， 即 含有 5 个 image; 右边 树 中 包含 6 个 节点 ， 即 含有 6 个 image。 其 中 ， 有 些 
image 标 记 了 加 粗 的 字段 ， 这 意味 该 image 代 表 某 一 种 容器 镜像 rootfs 的 最 上 层 image。 如 ubuntu: 14.04， 代 表 imagelD_3 为 该 类 型 容器 rootfs 的 最 上 层 ， 沿 着 该 节点 找到 树 的 根 节点 ， 可 以 发 现 路 径 上 还 
有 imagelD_ 2、imagelD_1 和 imagelD_0。 特 殊 的 是 ，imagelD_2 作 为 imagelD 3 的 父 镜像 ， 同 时 又 是 容器 镜像 ubuntu: 12.04 的 rootfs 中 的 最 上 层 ， 可 见 镜像 ubuntu: 14.04 只 是 在 镜像 ubuntu: 12.04 
之 上 再 另行 晋 加 了 一 层 。 因 此 ， 在 下 载 镜像 ubuntu: 12.04 以 及 ubuntu : 14.04 时 ， 只 会 下 载 一 份 imagelD_2、imagelD_ 1 和 imagelD_0， 实 现 image 的 。 同 时 ， 右 边 树 中 mysql: 5.6, mongo: 
2.2、debian: wheezy 和 debian: jessie 也 呈现 同样 的 关系 。 


8.6 layer 


在 Docker 中 ， 术 语 layer 是 一 个 与 image 含 义 较为 相近 的 词 。 容 器 镜像 的 rootfs 是 容器 只 读 的 文件 系统 ，rootfs 又 由 多 个 只 读 的 image 构 成 。 于 是 ，rootfs 中 每 个 只 读 的 image 都 可 以 称 为 一 个 layer。 


除了 只 读 的 image 之 外 ，Docker Daemon 在 创建 容器 时 会 在 容器 的 rootfs 之 上 ， 再 挂 载 一 层 读 写 文件 系统 ， 而 这 一 层 文件 系统 也 称 为 容器 的 一 个 layer， 常 被 称 为 top layer。 实 际 情况 下 ，Docker 还 会 
在 rootfs 和 top layer 之 间 再 挂 载 一 个 layer， 这 一 个 layer 中 主要 包含 的 内 容 是 /etc/hosts、/etc/hostname 以 及 /etc/resolv.conf， 一 般 这 一 个 layer 称 为 init layer。 为 了 简化 阐述 流程 ， 我 们 暂 不 提 init 


layer。 


因此 ， 总 之 ，Docker 容 器 中 每 一 层 只 读 的 image 以 及 最 上 层 可 读 写 的 文件 系统 ， 均 称 为 layer。 如 此 一 来 ，layer 的 范畴 比 image 多 了 一 层 ， 即 多 包含 了 最 上 层 的 读 写 文 件 系统 。 


有 了 layer 的 概念 ， 大 家 可 以 思考 这 样 一 个 问题 : 容器 文件 系统 分 为 只 读 的 rootfs， 以 及 可 读 写 的 top layer， 那 么 容器 运行 时 若 在 top layer 中 写 入 了 内 容 ， 这 些 内 容 是 否 可 以 持久 化 ， 并 且 也 被 
? 


Im 
c 
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E 


本 章 对 于 image 的 分 析 中 ， 提 到 了 image 有 复 用 的 特性 ， 既 然 如 此 ， 再 提出 一 个 更 为 大 胆 的 假设 : 容器 的 top layer 是 否 可 以 转变 为 image? 


答案 是 肯定 的 。Docker 的 设计 理念 中 ，top layer 转 变 为 image 的 行为 (Docker 中 称 为 commit 操 作 ) 进一步 释放 了 容器 rootfs 的 灵活 性 。Docker 的 开发 者 完全 可 以 基于 某 个 镜像 创建 容器 做 开发 工 
作 ， 并 且 无 论 在 开发 周期 的 哪个 时 间 点 ， 都 可 以 对 容器 进行 commit， 将 所 有 top layer 中 的 内 容 打 包 为 一 个 image， 构 成 一 个 新 的 镜像 。commit 完 毕 之 后 ， 用 户 完全 可 以 基于 新 的 镜像 ， 进 行 开 发 、 分 发 、 
测试 、 部 署 等 。 不 仅 Docker commit 的 原理 如 此 ， 基 于 Dockerfile 的 docker build 最 为 核心 的 思想 ， 也 是 不 断 将 容器 的 top layer 转 化 为 image。 


87 ”总结 


Docker 风 暴 席卷 全 球 并 非 偶然 。 如 今 的 云 计 算 时 代 下 ， 轻 量 级 容器 技术 与 灵活 的 镜像 技术 相 结合 ， 似 乎 颠覆 了 以 往 的 软件 交付 模式 ， 为 持续 集成 (Continuous Integration, CI) 与 持续 交付 
(Continuous Delivery, CD) 的 发 展 带 来 了 全 新 的 契机 。 


理解 Docker 的 “镜像 ”技术 ， 有 助 于 Docker 爱 好 者 更 好 地 使 用 、 创 建 以 及 交付 Docker 镜 像 。 基 于 此 ， 本 章 从 Docker 镜 像 的 4 个 重要 概念 入 手 ， 介 绍 了 Docker 镜 像 中 包含 的 内 容 ， 涉 及 的 技术 ， 以 及 如 
要 的 特性 。Docker 引 入 优秀 的 “镜像 ”技术 时 ， 着 实 使 容器 的 使 用 变 得 更 为 便利 ， 也 拓宽 了 Docker 的 使 用 范畴 。 然 而 ， 与 此 同时 ， 我 们 也 应 该 理性 地 看 待 镜像 技术 引入 时 ， 是 否 会 带 来 其 他 副作用 ， 如 镜 
像 技 术 是 否 会 带 来 性 能 问题 等 都 将 是 我 们 进一步 思考 的 话题 。 


T 


第 9 章 ”Docker 镜 像 下 载 


9.1 引言 


说 Docker Image 是 Docker 体 系 的 价值 所 在 ,没有 丝毫 的 硅 张 。Docker Image 作 为 容器 运行 环境 的 基石 ， 彻 底 解 放 了 Docker 容 器 的 生命 力 ， 也 激发 了 用 户 对 于 容器 运用 的 无 限 想 象 力 。 


玩 转 Docker， 必 然 离 不 开 Docker Imagefigszis, Am DASAR , Docker Image 来 自 何方 ，Docker Image 又 是 通过 何 种 途径 传输 到 用 户 的 宿主 机 ， 以 致 用 户 可 以 通过 Docker Image 创 建 容器 
的 呢 ? 回忆 初次 接触 Docker 的 场景 ， 大 家 肯定 对 两 条 命令 不 陌生 : docker pull 和 docker run。 这 两 条 命令 中 ， 正 是 前 者 实现 了 Docker Image 的 下 载 。Docker Daemon 在 执行 这 条 命令 时 ， 会 将 Docker 
Image 从 Docker Registry 下 载 至 本 地 ， 并 保存 在 本 地 Docker Daemon 管 理 的 Graph 中 。 


谈 及 Docker Registry，Docker 爱 好 者 首先 联想 到 的 自然 是 Docker Hub, Docker Hub 作 为 Docker 官 方 支持 的 Docker Registry， 拥 有 全 球 成 干 上 万 的 Docker Image。 全 球 的 Docker 爱 好 者 除了 可 以 
下 载 Docker Hub 开 放 的 镜像 资源 之 外 ， 还 可 以 向 Docker Hub 贡 献 镜像 资源 。 在 Docker Hub 上 ， 用 户 不 仅 可 以 享受 公有 镜像 带 来 的 便利 ， 而 且 可 以 创建 私有 镜像 库 。Docker Hub 是 全 国 最 大 的 Public 
Registry， 另 外 Docker 还 支持 用 户 自 定义 创建 Private Registry, Private Registry 主 要 的 功能 是 为 私有 网 络 提供 Docker 镜 像 的 专属 服务 ， 一 般 而 言 ， 镜 像 种 类 适应 用 户 需求 ， 私 密 性 较 高 ， 且 不 会 占用 公有 
网 络 带 宽 。 


本 章 主要 从 Docker 1.2.0 源 码 的 角度 分 析 Docker 下 载 Docker Image 的 过 程 。 分 析 内 容 主要 包括 以 下 4 部 分 : 


1) 概述 Docker 镜 像 下 载 的 流程 ， 涉 及 Docker Client, Docker Server 以 及 Docker Daemon; 


2) Docker Client 处 理 并 发 送 docker pull 请 求 ; 
3) Docker Server 接 收 docker pull 请 求 ， 创 建 镜像 下 载 任务 并 触发 执行 ; 


4) Docker Daemon 执 行 镜像 下 载 任务 ， 并 存储 镜像 至 Graph。 
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91 引言 


说 Docker Image 是 Docker 体 系 的 价值 所 在 ， 没 有 丝毫 的 夸张 。Docker Image 作 为 容器 运行 环境 的 基石 ， 彻 底 解 放 了 Docker 容 器 的 生命 力 ， 也 激发 了 用 户 对 于 容器 运用 的 无 限 想 象 力 。 


玩 转 Docker， 必 然 离 不 开 Docker Image 的 支持 。 然 而 “万 物 皆 有 源 ”，Docker Image 来 自 何方 ，Docker Image 又 是 通过 何 种 途径 传输 到 用 户 的 宿主 机 ， 以 致 用 户 可 以 通过 Docker Image 创 建 容器 
的 呢 ? 回忆 初次 接触 Docker 的 场景 ， 大 家 肯定 对 两 条 命令 不 陌生 : docker pull 和 docker run。 这 两 条 命令 中 ， 正 是 前 者 实现 了 Docker Image 的 下 载 。Docker Daemon 在 执行 这 条 命令 时 ， 会 将 Docker 


Image 从 Docker Registry 下 载 至 本 地 ， 并 保存 在 本 地 Docker Daemon 管 理 的 Graph 中 。 


谈 及 Docker Registry，Docker 爱 好 者 首先 联想 到 的 自然 是 Docker Hub, Docker Hub 作 为 Docker 官 方 支持 的 Docker Registry， 拥 有 全 球 成 干 上 万 的 Docker Image。 全 球 的 Docker 爱 好 者 除了 可 以 
下 载 Docker Hub 开 放 的 镜像 资源 之 外 ， 还 可 以 向 Docker Hub 贡 献 镜像 资源 。 在 Docker Hub 上 ， 用 户 不 仅 可 以 享受 公有 镜像 带 来 的 便利 ， 而 且 可 以 创建 私有 镜像 库 。Docker Hub 是 全 国 最 大 的 Public 


Registry， 另 外 Docker 还 支持 用 户 自 定义 创建 Private Registry, Private Registry 主 要 的 功能 是 为 私有 网 络 提供 Docker 镜 像 的 专属 服务 ， 一 般 而 言 ， 镜 像 种 类 适应 用 户 需求 ， 私 密 性 较 高 ， 且 不 会 占 
网 络 带 宽 。 


本 章 主要 从 Docker 1.2.0 源 码 的 角度 分 析 Docker 下 载 Docker Image 的 过 程 。 分 析 内 容 主要 包括 以 下 4 部 分 : 
1) 概述 Docker 镜 像 下 载 的 流程 ， 涉 及 Docker Client, Docker Server 以 及 Docker Daemon; 

2) Docker Client 处 理 并 发 送 docker pull 请 求 ; 

3) Docker Server 接 收 docker pull 请 求 ， 创 建 镜像 下 载 任务 并 触发 执行 ; 


4) Docker Daemon 执 行 镜像 下 载 任务 ， 并 存储 镜像 至 Graph。 


9.2 ”Docker 镜 像 下 载 流程 


Docker Image 作 为 Docker 生 态 中 的 精髓 ， 下 载 过 程 中 需要 Docker 架 构 中 多 个 组 件 的 协作 ， 下 载 流程 如 图 9-1 所 示 。 


Docker Client 


Docker Server 


Docker Registry 


Docker Daemon 


图 9-1 Docker 镜 像 下 载 流 程 图 


如 图 9-1 所 示 ，Docker Image 的 下 载 流程 可 以 归纳 为 以 下 3 个 步骤 : 


1) 用 户 通过 Docker Client 发 送 pull 请 求 ， 用 于 让 Docker Daemon 下 载 指定 名 称 的 镜像 ; 


2) Docker Server 接 收 Docker 镜 像 的 pull 请 求 ， 创 建 下 载 镜像 任务 并 触发 执行 ; 


3) Docker Daemon 执 行 镜像 下 载 任务 ， 从 Docker Registry 中 下 载 指定 镜像 ， 并 将 其 存储 于 本 地 的 Graph 中 。 


公有 


9.3 Docker Client 


Docker 架 构 中 ，Docker 用 户 的 角色 绝 大 多 数 由 Docker Client 来 扮演 。 因 此 ， 用 户 对 Docker 的 管理 请 求全 部 由 Docker Client 来 发 送 ，Docker 镜 像 下 载 请 求 自然 也 不 例外 。 


为 了 更 清晰 地 描述 Docker 镜 像 下 载 ， 本 节 结 合 有 具体 的 命令 进行 分 析 ， 命 令 如 下 : 


docker pull ubuntu:14.04 


此 命令 的 含义 是 : 通过 docker 二 进 制 可 执行 文件 ， 执 行 镜像 下 载 的 pull 命 令 ， 镜像 参数 为 ubuntu: 14.04， 镜 像 名 称 为 ubuntu， 镜 像 标 签 (tag) 为 14.04。 此 命令 一 经 发 起 ， 第 一 个 接受 并 处 理 的 
Docker 组 件 为 Docker Client， 执 行内 容 包括 以 下 三 个 步骤 : 


1) 解析 命令 中 与 Docker 镜 像 相关 的 参数 ; 
2) 配置 Docker 下 载 镜 像 时 所 需 的 认证 信息 ; 


3) 发 送 RESTful 请 求 至 Docker Daemon, 


94 Docker Server 


Docker Server 作 为 Docker Daemon 的 入 口 ， 所 有 Docker Client 发 送 请 求 都 由 Docker Server 接 收 。Docker Server 通 过 解析 请 求 的 URL 与 请 求 方法 ， 最 终 路 由 分 发 至 相应 的 处 理 方法 来 处 理 。Docker 
Server 的 创建 与 请 求 处 理 可 以 参见 第 5 章 。 


Docker Server 接 收 到 镜像 下 载 请 求 之 后 ， 通 过 路 由 分 发 最 终 由 具体 的 处 理 方法 一 一 postlImagesCreate 来 处 理 。postlmagesCreate 的 源码 实现 位 于 ./docker/api/server/server.go#L466-L524， 其 执 
行 流程 主要 分 为 3 部 分 : 


1) 解析 HTTP 请 求 中 包含 的 请 求 参 数 ， 包 括 URL 中 的 查询 参数 、HTTP Header 中 的 认证 信息 等 ; 


2) 创建 镜像 下 载 Job， 并 为 该 Job 配 置 环境 变量 ; 


3) 触发 执行 镜像 下 载 Job。 


9.5 Docker Daemon 


Docker Daemon 是 完成 Job 执 行 的 主要 载体 。Docker Server 为 镜像 下 载 Job 准 备 好 所 有 的 参数 配置 之 后 ， 只 等 Docker Daemon 来 完成 执行 ， 并 返回 相应 的 信息 ，Docker Server 再 将 响应 信息 返 
Docker Client, Docker Daemon 对 于 镜像 下 载 Job 的 执行 涉及 的 内 容 较 多 : 首先 解析 Job 参 数 ， 获 取 Docker 镜 像 的 repository、tag 以 及 Docker Registry 信 息 等 ; 随后 与 Docker Registry 建 立会 话 
(session) ; 然后 通过 会 话 下载 Docker 镜 像 ; 接着 将 Docker 镜 像 下 载 至 本 地 并 存储 于 Graph 中 ; 最 后 在 TagStore 中 标记 该 镜像 。 


回 
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Docker Daemon 对 于 镜像 下 载 Job 的 执行 主要 依靠 CmdPull 函 数 。 这 个 CmdPull 函 数 与 Docker Client 的 CmdPull 函 数 完全 不 同 ， 前 者 是 为 了 代替 用 户 发 送 镜像 下 载 的 请 求 至 Docker Daemon, 而 
Docker Daemon 的 CmdPull 函 数 则 实现 代 蔡 用 户 真 正 完 成 镜像 下 载 的 任务 。 调 用 CmdPull 函 数 的 对 象 类 型 为 Tagstore， 其 源码 实现 位 于 ./dockergraphyVpull.go。 


Docker 镜 像 给 Docker 容 器 的 运行 带 来 了 无 限 的 可 能 性 ， 诸 如 Docker Hub 之 类 的 Docker Registry 又 使 得 Docker 镜 像 在 全 球 的 开发 者 之 间 共 享 。Docker 镜 像 的 下 载 是 使 用 Docker 的 第 一 个 步骤 。 
Docker 爱 好 者 若 能 熟练 掌握 其 中 的 原理 ， 必 定 能 对 Docker 的 很 多 概念 有 更 为 清晰 的 认识 ， 对 Docker 容 器 的 运行 、 管 理 等 均 是 有 百 利 而 无 一 害 。 


Docker 镜 像 的 下 载 需 要 Docker Client, Docker Server, Docker Daemon 以 及 Docker Registry 四 者 协同 合作 完成 。 本 章 从 源码 的 角度 分 析 了 四 者 各 自 扮演 的 角色 ， 分 析 过 程 中 还 涉及 多 种 Docker 概 


念 ， 如 repository、tag、TagStore、session、image、layer、image json 和 graph 等 。 
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10.1 引言 


Docker Hub 汇 总 众多 Docker 用 户 的 镜像 ， 极 大 地 发 挥 Docker 镜 像 开放 的 思想 。Docker 用 户 在 全 球 任意 一 个 位 置 ， 都 可 以 与 Docker Hub 交 互 ， 分 享 自己 构建 的 镜像 至 Docker Hub， 当 然 ， 也 完全 可 
以 下 载 男 一 半球 Docker 开 发 者 上 传 至 Docker Hub 的 Docker 镜 像 。 


无 论 是 上 传 ， 还 是 下 载 Docker 镜 像 ， 镜 像 必 然 都 会 以 某 种 形式 存储 在 Docker Daemon 所 在 的 宿主 机 文件 系统 中 。 关 于 Docker 镜 像 在 宿主 机 中 的 存储 ， 关 键 点 在 于 : 在 本 地 文件 系统 中 以 何 种 组 织 形式 
被 Docker Daemon 有 效 地 统一 化 管理 。 这 种 管理 可 以 使 得 Docker Daemon 创 建 Docker 容 器 服务 时 ， 方 便 获取 镜像 并 完成 Union Mount 操 作 ， 为 容器 准备 初始 化 的 文件 系统 。 


本 章 主要 从 Docker 1.2.0 源 码 的 角度 ， 分 析 Docker Daemon 下 载 镜像 过 程 中 存储 Docker 镜 像 的 环节 。 本 章 分 析 的 内 容 有 以 下 5 部 分 : 


1) 概述 Docker 镜 像 存 储 的 执行 入 口 ， 并 简要 介绍 存储 流程 的 四 个 步 


2) 验证 镜像 ID 的 有 效 性 ; 
3) 创建 镜像 存储 路 径 ; 
4) 存储 镜像 内 容 ; 


5) 在 Graph 中 注册 镜像 ID。 


10.1 引言 


Docker Hub 汇 总 众多 Docker 用 户 的 镜像 ， 极 大 地 发 挥 Docker 镜 像 开 放 的 思想 。Docker 用 户 在 全 球 任意 一 个 位 置 ， 都 可 以 与 Docker Hub 交 互 ， 分 享 
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己 构建 的 镜像 至 Docker Hub， 当 然 ， 也 完全 可 


以 下 载 另 一 半球 Docker 开 发 者 上 传 至 Docker Hub 的 Docker 镜 像 。 


无 论 是 上 传 ， 还 是 下 载 Docker 镜 像 ， 镜 像 必 然 都 会 以 某 种 形式 存储 在 Docker Daemon 所 在 的 宿主 机 文件 系统 中 。 关 于 Docker 镜 像 在 宿主 机 中 的 存储 ， 关 键 点 在 了 


:在 本 地 文件 系统 中 以 何 种 组 织 形式 


被 Docker Daemon 有 效 地 统一 化 管理 。 这 种 管理 可 以 使 得 Docker Daemon 创 建 Docker 容 器 服务 时 ， 方 便 获取 镜像 并 完成 Union Mount 操 作 ， 为 容器 准备 初始 化 的 文件 系统 。 


本 章 主 要 从 Docker 1.2.0 源 码 的 角度 ， 分 析 Docker Daemon 下 载 镜像 过 程 中 存储 Docker 镜 像 的 环节 。 本 章 分 析 的 内 容 有 以 下 5 部 分 : 


1) 概述 Docker 镜 像 存 储 的 执行 入 口 ， 并 简要 介绍 存储 流程 的 四 个 步骤 ; 


2) 验证 镜像 ID 的 有 效 性 ; 
3) 创建 镜像 存储 路 径 ; 
4) 存储 镜像 内 容 ; 


5) 在 Graph 中 注册 镜像 1D。 


10.2 ”镜像 注册 


Docker Daemon 执 行 镜像 下 载 任务 时 ， 从 Docker Registry 处 下 载 指定 镜像 之 后 ， 仍 需要 将 镜像 合理 地 存储 于 宿主 机 的 文件 系统 中 。 更 为 具体 而 言 ， 存 储 工作 分 为 两 个 部 分 : 


1) 存储 镜像 内 容 ; 


2) 在 Graph 中 注册 镜像 信息 。 


P 


存储 镜像 内 容 ， 意 味 着 Docker Daemon 所 在 宿主 机 上 已 经 存在 镜像 的 所 有 内 容 ， 除 此 之 外 ，Docker Daemon 仍 需要 对 所 存储 的 镜像 进行 统计 备案 ， 以 便 用 户 在 后 续 的 镜像 管理 与 使 有 


提 到 镜像 内 容 ， 需 要 强调 的 是 ， 每 一 个 layer 的 Dockerlmage 内 容 都 可 以 认为 由 两 个 部 分 组 成 : 镜像 中 每 一 个 layer 中 存储 的 文件 系统 内 容 ， 这 部 分 内 容 一 般 可 以 认为 是 未 来 Docker 容 器 的 静态 文件 内 
A 另 一 部 分 内 容 指 的 是 容器 的 json 文 件 ，json 文 件 代表 的 信息 除了 容器 的 基本 属性 信息 之 外 ， 还 包括 未 来 容器 运行 时 的 动态 信息 ， 如 ENV 等 信息 。 


过 程 中 ， 可 以 有 


据 可 循 。 为 此 ，Docker Daemon 设 计 了 Graph,， 使 


Graph 来 接管 这 部 分 的 工作 。Graph 负 责 记 录 有 哪些 镜像 已 经 正确 存储 ， 供 Docker Daemon 调 用 。 


Docker Daemon 执 行 CmdPull 任 务 的 pulllmage 阶 段 时 ， 实 现 Docker 镜 像 存储 与 记录 的 源码 位 于 ./docker/graph/pull.go#L283-L285， 如 下 : 


err = s.graph.Register(imgJSON,utils.ProgressReader(layer, imgSize, out, sf, false, utils.TruncateID(id), 


"Downloading" ),img) 


以 上 源码 的 实现 ， 实 际 调用 了 函数 Register，Register 函 数 的 定义 位 于 ./docker/graph/graph.go#L162-L218， 如 下 : 


func (graph *Graph) Register(jsonData []byte, layerData archive.ArchiveReader, img *image.Image) (err error) 


分 析 以 上 Register 函 数 的 定义 ， 可 以 得 出 以 下 内 容 : 


1) 函数 名 称 为 Register; 


2) 函数 调用 者 类 型 为 Graph; 


3) 传 入 函数 的 参数 有 3 个 : 第 一 个 为 jsonData， 


4) 函数 返回 对 象 为 err， 类 型 为 error。 


Register 函 数 的 运行 流程 如 图 10-1 所 示 。 


类 型 为 数组 ; 第 二 个 为 layerData， 类 型 为 archive.ArchiveReader; 第 三 个 为 Img， 类 型 为 *image.lmage; 
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图 10-1 Register 函数 执行 流程 


10.3 ”验证 镜像 ID 


Docker 镜 像 注册 的 第 一 个 步骤 是 验证 Docker 镜 像 的 D。 此 步骤 确保 镜像 ID 命名 的 合法 性 。 就 功能 而 言 ， 这 部 分 内 容 提高 了 Docker 镜 像 存储 环节 的 鲁 棒 性 。 验 证 镜像 |D 由 三 个 环节 组 成 。 
1) 验证 镜像 ID 的 合法 性 ; 
2) 验证 镜像 是 否 已 存在 ; 


3) 初始 化 镜像 目录 。 


验证 镜像 ID 的 合法 性 使 用 包 utils 中 的 ValidatelD 函 数 完成 ， 实 现 源码 位 于 ./dockervgraph/graph.go#L171-L173， 如 下 : 


if err := utils.ValidateID(img.ID); err != nil ( 
return err 


} 


Validate DRŠKE, Docker Dameon 检 验 了 镜像 1D 是 否 为 空 ， 以 及 镜像 ID 中 是 否 存在 字符 “: ”， 以 上 两 种 情况 只 要 其 中 之 一 成 立 ，Docker Daemon 就 认为 镜像 ID 不 合法 ， 不 予 执行 后 续 
内 容 。 


镜像 1D 的 合法 性 验证 完毕 之 后 ，Docker Daemon 接 着 验证 镜像 是 否 已 经 存在 于 Graph 中 。 若 该 镜像 已 经 存在 于 Graph 中 ， 则 Docker Daemon 返 回 相应 错误 ， 不 予 执行 后 续 内 容 。 代 码 实现 如 下 : 


if graph.Exists(img.ID) ( 
return fmt.Errorf ("Image $s already exists", img.ID) 


} 


验证 工作 完成 之 后 ，Docker Daemon 为 镜像 准备 存储 路 径 。 该 部 分 源码 实现 位 于 ./docker/graph/graph.go#L182-L196， 如 下 : 


if err := os.RemoveAll(graph.ImageRoot(img.ID)); err != nil && !os.IsNotExist (err) { 
return err 


l 
// If the driver has this ID but the graph doesn't, remove it from the driver to start fresh. 
// (the graph is the source of truth). 
// Ignore errors, since we don't know if the driver correctly returns ErrNotExist. 
// (FIXME: make that mandatory for drivers). 
graph.driver.Remove (img.ID) 
tmp, err := graph.Mktemp ("") 
defer os.RemoveAll (tmp) 
if err != nil ( 
return fmt.Errorf("Mktemp failed: $s", err) 
} 


Docker Daemon 为 镜像 初始 化 存储 路 径 ， 实 则 首先 删除 属于 新 镜像 的 存储 路 径 ， 即 如 果 该 镜像 路 径 已 经 在 文件 系统 中 存在 ， 立 即 删除 该 路 径 ， 确 保存 储 镜像 时 不 会 出 现 路 径 冲 突 问题 ， 接 着 还 删除 
graph.driver 中 的 指定 内 容 ， 即 如 果 该 镜像 在 graph.driver 中 存在 ， 纯 载 该 镜像 在 宿主 机 上 的 目录 ， 并 将 该 目录 完全 删除 。 以 AUFS 这 种 类 型 的 graphdriver 为 例 ， 镜 像 内 容 存放 在 /var/lib/docker/aufs/diff 
目录 下 ,而 镜像 会 被 挂 载 至 目录 /var/lib/docker/aufs/mnt 下 的 指定 位 置 。 


至 此 ， 验 证 Docker 镜 像 ID 的 工作 已 经 完成 ， 并 且 Docker Daemon 已 经 完成 对 镜像 存储 路 径 的 初始 化 ， 使 得 后 续 Docker 镜 像 存储 时 存储 路 径 不 会 冲突，graph.driver 对 该 镜像 的 挂 载 也 不 会 冲突 。 


10.4 ”创建 镜像 路 径 


创建 镜像 路 径 ， 是 镜像 存储 流程 中 的 一 个 必 备 环节 ， 这 一 环节 直接 让 Docker 使 用 者 了 解 以 下 概念 : 镜像 以 何 种 形式 存在 于 本 地 文件 系统 的 何 处 。 创 建 镜 像 路 径 完毕 之 后 ，Docker Daemon 首 先 将 镜像 
的 所 有 祖先 镜像 通过 aufs 文 件 系统 挂 载 至 mnt 下 的 指定 点 ， 最 终 直 接 返 回 镜像 所 在 rootfs 的 路 径 ， 以 便 后 续 直 接 在 该 路 径 下 解压 Docker 镜 像 的 具体 内 容 (只 包含 layer 内 容 ) 。 


10.5 “存储 镜像 内 容 


存储 镜像 内 容 ， 意 味 着 Docker Daemon 以 及 验证 过 镜像 |D， 同 时 还 为 镜像 准备 了 存储 路 径 ， 并 返回 了 其 所 有 祖先 镜像 执行 Union Mount 操 作 后 的 路 径 。 万 事 俱 备 ， 只 欠 “镜像 内 容 的 存储 ”。 


Docker Daemon 为 了 存储 镜像 具体 内 容 完成 的 工作 很 简单 ， 仅 仅 是 通过 某 种 合适 的 方式 将 两 部 分 内 容 存储 于 本 地 文件 系统 并 进行 有 效 管理 ， 两 部 分 内 容 是 镜像 压缩 内 容 、 镜 像 json 信 息 。 


存储 镜像 内 容 的 源码 实现 位 于 ./docker/graph/graph.go#L209-L211， 如 下 : 


if err := image.StoreImage (img, jsonData, layerData, tmp, rootfs); err != nil ( 
return err 


} 


其 中 ，Storelmage 函 数 的 定义 位 于 ./docker/docker/image/image.go#L74， 如 下 : 


func StoreImage (img *Image, jsonData []byte, layerData archive.ArchiveReader, root, layer string) error { 


分 析 Storelmage 函 数 的 定义 ， 可 以 得 出 以 下 信息 : 
1) 函数 名 称 : Storelmage; 


2) 传 入 函数 的 参数 名 : img, jsonData, layerData, root, layer; 


3) 函数 返回 类 型 error。 
传 入 参数 的 含义 如 表 10-1 所 示 。 
表 10-1 StoreImasge 函 数 的 传 入 参数 
img 通过 下 载 的 imgJSON 信息 创建 出 的 Image 对 象 实例 
jsonData Docker Daemon 之 前 下 载 的 imgJSON 信息 
layerData 镜像 作为 一 个 layer 的 压缩 包 ， 包 含 镜 像 的 具体 文件 内 容 
Toot graphdriver 根 目录 下 创建 的 临时 文件 ”tmp”， 值 为 /var/lib/docker/aufs/_tmp 
layer 挂 载 完 所 有 祖先 镜像 之 后 ， 该 镜像 在 mnt 目录 下 的 路 径 


掌握 Storelmage 函 数 传 入 参数 的 含义 之 后 ， 理 解 其 实现 就 十 分 简单 。 总 体 而 言 ，Storelmage 亦 可 以 分 为 三 个 步骤 : 
1) 解压 镜像 内 容 layerData 至 diff 目 录 ; 

2) 收集 镜像 所 占 空间 大 小 ， 并 记录 ; 

3) 将 jsonData 信 息 写 入 临时 文件 。 


下 面 详细 介绍 三 个 步骤 的 实现 。 


10.6 ”注册 镜像 ID 


Docker Daemon 执 行 完 镜像 的 Storelmage 操 作 ， 回 到 Register 函 数 之 后 ， 执 行 镜 像 的 commit 操 作 ， 即 完成 镜像 在 Graph 中 的 注册 。 


注册 镜像 的 代码 实现 位 于 ./docker/docker/graph/graph.go#L212-L216， 如 下 : 


// commit 

if err := os.Rename (tmp, graph.ImageRoot(img.ID)); err != nil { 
return err 

} 

graph.idIndex.Add (img. ID) 


10.5 节 存储 镜像 过 程 中 使 用 到 的 临时 文件 tmp 在 注册 镜像 环节 有 所 体现 。 关 于 镜像 的 注册 行为 ， 第 一 步 就 是 将 tmp 文件 (/var/lib/docker/graph/ tmp) 重 命名 为 graph.ImageRoot (img.ID) ， 实 
则 为 /var/lib/docker/graph/<img.ID>。 使 得 Docker Daemon 在 而 后 的 操作 中 可 以 通过 img.ID 在 /var/lib/docker/graph 目 录 下 搜索 到 相应 镜像 的 json 文 件 与 layersize 文 件 。 


成 功 为 json 文 件 与 layersize 文 件 配置 完 正确 的 路 径 之 后 ，Docker Daemon 执 行 的 最 后 一 个 步骤 为 : 添加 镜像 ID 至 graph.idlndex。 源 代码 实现 是 graph.idlndex.Add (img.ID) ，Graph 中 idlndex 类 型 
为 *truncindex.Truncindex，Trunclndex 的 定义 位 于 ./docker/docker/pkg/truncindex/truncindex.go#L22-L28， 如 下 : 


// TruncIndex allows the retrieval of string identifiers by any of their unique prefixes. 
// This is used to retrieve image and container IDs by more convenient shorthand prefixes. 
type TruncIndex struct ( 

sync.RWMutex 

trie *patricia.Trie 

ids map[string]struct(]) 


Docker 用 户 使 用 Docker 镜 像 时， 一般 可 以 通过 指定 镜像 ID 来 定位 镜像 ， 如 Docker 官 方 的 mongo: 2.6.158(&1D73c35c0961174d51035d6e374ed9815398b779296b5f0ffceb7613c8199383f4b1, iX 
1D 长 度 为 64。 当 Docker 用 户 指定 运行 这 个 Mongo 镜 像 Repository 中 tag 为 2.6.1 的 镜像 时 ， 完 全 可 以 通过 64 位 的 镜像 ID 来 指定 ， 如 下 : 


docker run -it c35c0961174d51035d6e374ed9815398b779296b5f0ffceb7613c8199383f4b1 /bin/bash 


然而 ， 记 录 如 此 长 的 镜像 ID， 对 于 Docker 用 户 来 说， 稍 显 不 切实 际 ， 而 Trunclndex 的 概念 则 极 大 地 帮助 Docker 用 户 可 以 通过 简短 的 ID 定位 到 指定 的 镜像 ， 使 得 Docker 镜 像 的 使 用 变 得 尤为 方便 。 原 理 
是 : Docker 用 户 指定 镜像 ID 的 前 缀 ， 只 要 前 缀 满足 在 全 局 所 有 的 镜像 |D 中 唯一 ，Docker Daemon 就 可 以 通过 Trunclndex 定 位 到 唯一 的 镜像 |D。 而 graph.idlndex.Add (img.ID) 正式 完成 将 img.ID 添 加 并 
保存 至 Trunclndex 中 。 


为 了 达到 上 一 条 命令 的 效果 ，Docker 用 户 完全 可 以 使 用 Trunclndex 的 方式 ， 当 然 ， 前 提 是 c35 这 个 字符 串 作 为 前 缀 全 局 唯一 ， 命 令 如 下 : 


docker run -it c35 /bin/bash 


至 此 ，Docker 镜 像 存 储 的 整个 流程 已 经 完成 。 概 括 而 言 ， 它 主要 包含 验证 镜像 、 存 储 镜 像 、 注 册 镜像 三 个 步骤 。 


107 总结 


IOA 


Docker 镜 像 的 存储 ， 使 得 Docker Hub 上 的 镜像 能 够 遍布 世界 各 地 变 为 现实 。Docker 镜 像 在 Docker Registry 中 的 存储 方式 与 本 地 化 的 存储 方式 并 非 一 致 。Docker Daemon 必 须 针 对 自身 的 
graphdriver 类 型 ， 选 择 适 配 的 存储 方式 ， 实 施 镜像 的 存储 。 本 章 也 在 不 断 强 调 一 个 事实 ， 即 Docker 镜 像 并 非 仅仅 包含 文件 系统 中 的 静态 文件 ， 除 此 之 外 ， 它 还 包含 镜像 的 json 信 息 ，json 信 息 中 有 Docker 
容器 的 配置 信息 ， 如 暴露 端口 、 环 境 变量 等 。 


可 以 说 Docker 容 器 的 运行 严重 依赖 于 Docker 镜 像 ， 因 此 了 解 Docker 镜 像 的 由 来 就 变 得 尤为 重要 。Docker 镜 像 的 下 载 、Docker 镜 像 的 打包 以 及 构建 新 的 Docker 镜 像 ， 都 无 法 跳出 镜像 存储 的 范畴 。 
Docker 镜 像 的 存储 知识 ， 也 有 助 于 Docker 其 他 概念 的 理解 ， 如 docker commit, docker build, docker run 等 。 


第 11 章 docker build 实 现 


11.1 引言 


Docker 镜 像 在 Docker 生 态 圈 中 起 到 的 作用 非 同一 般 。 一 起 来 看 Docker 的 发 展 ， 我 们 甚至 可 以 如 此 评价 : Docker 正 是 凭借 着 其 灵活 的 镜像 技术 ， 以 及 革命 性 的 镜像 托管 服务 Docker Hub， 在 云 计 算 时 
代 占 据 了 行业 内 极为 有 利 的 位 置 。 其 自身 的 Dockerfile 技 术 甚至 有 可 能 取代 传统 软件 发 布 的 模式 ， 成 为 行业 内 更 快捷 、 更 有 效 、 更 易于 部 署 与 管理 的 软件 发 布 模式 。 


Docker 诞 生 之 前 ， 软 件 的 发 布 模式 一 直 以 代码 为 核心 。 软 件 开发 者 首先 在 开发 环境 中 开发 软件 ， 开 发 到 一 定 阶段 后 ， 开 发 者 提交 代码 至 托管 平台 ; 软件 测试 者 接着 在 测试 环境 中 部 署 软件 代码 ， 做 相应 
的 测试 工作 并 提交 测试 报告 ， 软件 开发 者 与 测试 者 将 软件 完善 至 一 定 阶段 后 交付 ， 交 付 形式 一 般 仍 旧 是 代码 。 最 终 交 付 的 软件 ， 仍 然 需 要 在 另外 的 环境 中 部 署 ， 因 此 软件 对 部 署 环境 的 要 求 需要 通过 软件 说 
明 书 的 形式 交付 给 客户 。 然 而 ， 真 实 的 部 署 环境 并 不 一 定 能 与 软件 有 效 地 结合 ， 这 也 是 以 代码 为 核心 的 软件 发 布 模式 一 直 以 来 的 痛 点 。 


Docker 诞 生 之 后 ， 软 件 发 布 模式 似 平 有 了 新 的 转机 。 软 件 代码 依然 是 软件 的 重要 组 成 部 分 ， 然 而 ， 与 以 往 不 同 的 是 ，Docker 生 态 圈 中 软件 的 发 布 使 得 代码 与 运行 环境 并 不 分 离 ， 而 是 将 软件 运行 环境 
也 圈 入 软件 范畴 ， 一 并 交付 给 客户 。 客 户 在 获得 软件 之 后 ， 并 不 需要 额外 地 配置 环境 ， 而 是 能 够 直接 运行 软件 。 这 种 新 模式 的 诞生 极 大 地 吸引 了 开发 者 的 眼球 ， 传 统 软件 发 布 浆 端 的 剔除 ， 也 逐渐 使 得 
Docker 阵 营 越 来 越 庞大 。 


软件 发 布 模式 的 革新 ， 并 非 信 手 牛 来 ， 革 新 理念 的 外 表 下 是 前 卫 的 创新 意识 ， 以 及 创新 意识 下 的 技术 积淀 。Docker 的 镜像 技术 ， 可 以 说 是 传统 联合 文件 系统 在 云 时 代 迎 来 的 又 一 个 春天 。 在 镜像 技术 之 
上 ，Dockerfile 的 设计 则 可 以 认为 是 Docker 公 司 在 镜像 技术 上 抽象 出 的 一 个 全 新 软件 标准 。 此 标准 一 出 ， 软 件 开发 者 有 能 力 以 一 个 超 乎 想象 的 速度 ， 发 布 包含 运行 环境 的 软件 ， 并 通过 Docker Hub 的 方式 
串联 全 世界 。 


第 8 章 、 第 9 章 以 及 第 10 章 分 别 介绍 了 Docker 镜 像 的 原理 、Docker 镜 像 的 下 载 以 及 Docker 镜 像 的 存储 。 在 这 些 镜像 技术 的 基础 之 上 ， 理 解 在 Docker 环 境 中 如 何 通过 Dockerfile 构 建 自己 的 Docker 镜 
像 ， 就 显得 意义 重大 。 


本 章 从 Docker 1.2.0 的 源码 出 发 ， 分 析 用 户 通过 Dockerfile 构 建 出 一 个 Docker 镜 像 的 来 龙 去 脉 。 


分 析 之 前 ， 我 们 首先 来 简单 了 解 docker build 的 作用 。 简 单 而 言 ， 用 户 可 以 通过 一 个 自 定义 的 Dockerfile 文 件 以 及 相关 内 容 ， 从 一 个 基础 镜像 起 步 ， 对 于 Dockerfile 中 的 每 一 条 命令 ， 都 在 原先 的 镜像 
layer 之 上 再 额外 构建 一 个 新 的 镜像 layer， 直 至 构建 出 用 户 所 需 的 镜像 。 


由 于 docker build 命 令 由 Docker 用 户 发 起 ， 故 docker build 的 流程 会 贯穿 Docker Client, Docker Server 以 及 Docker Daemon 这 三 个 重要 的 Docker 模 块 。 本 章 也 正 是 以 这 三 个 Docker 模 块 为 主题 ， 
分 析 docker build 命 令 的 执行 ， 其 中 Docker Daemon 作 为 Docker 的 重 中 之 重 ， 本 章 对 其 的 分 析 也 将 会 更 加 详细 。 具 体 而 言 ， 本 章 内 容 包 含 以 下 3 部 分 : 


1) 概述 docker build 命 令 执 行 的 流程 ， 包 含 Docker Client, Docker Server 以 及 Docker Daemon; 
2) 详细 分 析 Docker Daemon 对 Dockerfile 的 build 实 现 ; 


3) 简要 分 析 Dockerfile 中 的 命令 在 Docker Daemon 中 的 执行 流程 。 


第 11 章 docker build 实 现 


11.1 引言 


Docker 镜 像 在 Docker 生 态 圈 中 起 到 的 作用 非 同一 般 。 一 起 来 看 Docker 的 发 展 ， 我 们 甚至 可 以 如 此 评价 : Docker 正 是 凭借 着 其 灵活 的 镜像 技术 ， 以 及 革命 性 的 镜像 托管 服务 Docker Hub， 在 云 计算 时 
代 占 据 了 行业 内 极为 有 利 的 位 置 。 其 自身 的 Dockerfile 技 术 甚至 有 可 能 取代 传统 软件 发 布 的 模式 ， 成 为 行业 内 更 快捷 、 更 有 效 、 更 易于 部 署 与 管理 的 软件 发 布 模式 。 


Docker 诞 生 之 前 ， 软 件 的 发 布 模式 一 直 以 代码 为 核心 。 软 件 开发 者 首先 在 开发 环境 中 开发 软件 ， 开 发 到 一 定 阶段 后 ， 开 发 者 提交 代码 至 托管 平台 ; 软件 测试 者 接着 在 测试 环境 中 部 署 软件 代码 ， 做 相应 
的 测试 工作 并 提交 测试 报告 ;软件 开发 者 与 测试 者 将 软件 完善 至 一 定 阶段 后 交付 ， 交 付 形式 一 般 仍 旧 是 代码 。 最 终 交 付 的 软件 ， 仍 然 需 要 在 另外 的 环境 中 部 署 ， 因 此 软件 对 部 署 环境 的 要 求 需要 通过 软件 说 
明 书 的 形式 交付 给 客户 。 然 而 ， 真 实 的 部 署 环境 并 不 一 定 能 与 软件 有 效 地 结合 ， 这 也 是 以 代码 为 核心 的 软件 发 布 模式 一 直 以 来 的 痛 点 。 


Docker 诞 生 之 后 ， 软 件 发 布 模式 似 平 有 了 新 的 转机 。 软 件 代码 依然 是 软件 的 重要 组 成 部 分 ， 然 而 ， 与 以 往 不 同 的 是 ，Docker 生 态 圈 中 软件 的 发 布 使 得 代码 与 运行 环境 并 不 分 离 ， 而 是 将 软件 运行 环境 
也 圈 入 软件 范畴 ， 一 并 交付 给 客户 。 客 户 在 获得 软件 之 后 ， 并 不 需要 额外 地 配置 环境 ， 而 是 能 够 直接 运行 软件 。 这 种 新 模式 的 诞生 极 大 地 吸引 了 开发 者 的 眼球 ， 传 统 软件 发 布 浆 端 的 剔除 ， 也 逐渐 使 得 
Docker 阵 营 越 来 越 庞大 。 


软件 发 布 模式 的 革新 ， 并 非 信 手 牛 来 ， 革 新 理念 的 外 表 下 是 前 卫 的 创新 意识 ， 以 及 创新 意识 下 的 技术 积淀 。Docker 的 镜像 技术 ， 可 以 说 是 传统 联合 文件 系统 在 云 时 代 迎 来 的 又 一 个 春天 。 在 镜像 技术 之 
上 ，Dockerfile 的 设计 则 可 以 认为 是 Docker 公 司 在 镜像 技术 上 抽象 出 的 一 个 全 新 软件 标准 。 此 标准 一 出 ， 软 件 开发 者 有 能 力 以 一 个 超 乎 想象 的 速度 ， 发 布 包含 运行 环境 的 软件 ， 并 通过 Docker Hub 的 方式 
串联 全 世界 。 


第 8 章 、 第 9 章 以 及 第 10 章 分 别 介绍 了 Docker 镜 像 的 原理 、Docker 镜 像 的 下 载 以 及 Docker 镜 像 的 存储 。 在 这 些 镜像 技术 的 基础 之 上 ， 理 解 在 Docker 环 境 中 如 何 通过 Dockerfile 构 建 自己 的 Docker 镜 
像 ， 就 显得 意义 重大 。 


本 章 从 Docker 1.2.0 的 源码 出 发 ， 分 析 用 户 通过 Dockerfile 构 建 出 一 个 Docker 镜 像 的 来 龙 去 脉 。 


分 析 之 前 ， 我 们 首先 来 简单 了 解 docker build 的 作用 。 简 单 而 言 ， 用 户 可 以 通过 一 个 自 定 义 的 Dockerfile 文 件 以 及 相关 内 容 ， 从 一 个 基础 镜像 起 步 ， 对 于 Dockerfile 中 的 每 一 条 命令 ， 都 在 原先 的 镜像 
layer 之 上 再 额外 构建 一 个 新 的 镜像 layer， 直 至 构建 出 用 户 所 需 的 镜像 。 


由 于 docker build 命 令 由 Docker 用 户 发 起 ， 故 docker build 的 流程 会 贯穿 Docker Client, Docker Server 以 及 Docker Daemon 这 三 个 重要 的 Docker 模 块 。 本 章 也 正 是 以 这 三 个 Docker 模 块 为 主题 ， 
分 析 docker build 命 令 的 执行 ， 其 中 Docker Daemon 作 为 Docker 的 重 中 之 重 ， 本 章 对 其 的 分 析 也 将 会 更 加 详细 。 具 体 而 言 ， 本 章 内 容 包 含 以 下 3 部 分 : 


1) 概述 docker build 命 令 执 行 的 流程 ， 包 含 Docker Client, Docker Server 以 及 Docker Daemon; 
2) 详细 分 析 Docker Daemon 对 Dockerfile 的 build 实 现 ; 


3) 简要 分 析 Dockerfile 中 的 命令 在 Docker Daemon 中 的 执行 流程 。 


11.2 docker build 执 行 流程 


docker build 可 以 帮助 Docker 用 户 通 过 Dockerfile 的 形式 构建 出 自己 的 Docker 镜 像 。 更 为 细致 的 描述 是 : 用 户 通 过 Docker Client 向 Docker Server 发 送 一 条 docker build 命 令 ， 发 送 命 令 时 ， 用 户 需 
首先 指定 Dockerfile 以 及 相关 内 容 ， 并 通过 Docker Client 将 请 求 发 出 ; Docker Server 接 收 请 求 之 后 ， 将 其 路 由 转发 至 相应 的 处 理 方法 ; Docker Daemon 负 责 执行 请 求 处 理 的 处 理 方法 ， 解 析 Dockerfile 并 


构建 出 最 终 的 镜像 。 


Docker Client, Docker Server 以 及 Docker Daemon 协 同 完 成 build 任 务 的 流程 图 如 图 11-1 所 示 。 


下 面 几 节 将 从 Docker Client、Docker Server 以 及 Docker Daemon 三 个 方面 分 析 docker build 的 流程 。 


Docker Server 


解析 请 求 参数 


Docker Client 
创建 并 触发 build 任 务 


定义 并 解析 flag 参 数 


Docker Daemon 
采集 Dockerfile 内 容 


构建 POST 请 求 内 容 


解析 任务 参数 


获取 Dockerfile 内 容 


发 送 POST 请 求 


创建 buildFile 对 象 


执行 build 任 务 


图 11-1 dockerbuild 的 流程 图 


11.3 ”Dockerfile 命 令 解 析 流 程 


Docker Server 交 付 给 Docker Daemon 的 内 容 是 一 系列 参数 ， 以 及 Dockerfile 相 关内 容 压缩 后 的 context 对 象 ， 我 们 习惯 于 将 后 者 称 为 原材料 。Dockerfile 命 令 解 析 也 是 从 原材料 入 手 ， 以 下 是 build 函 


L. 创建 临时 文件 


数 的 执行 流程 ， 如 图 11-5 所 示 。 


2. MEJE context 


. jx: HX Dockerfile 


图 11-5 ”build 函数 执行 流程 图 


函数 build 的 执行 过 程 中 ， 第 1~3 步 ， 以 及 第 5 步 的 执行 内 容 及 意义 简单 而 清晰 ， 本 节 主 要 分 析 第 4 步 
于 ./docker/docker/daemon/build.go#898-L912， 如 下 : 


逐 行 解析 Dockerfile。 逐 行 解析 Dockerfile 命 令 的 代码 位 


for , line := range strings.Split(dockerfile, "\n") ( 
"line = strings.Trim(strings.Replace(line, "Nt", " ", -1), " \t\r\n") 
if len(line) == 0 ( 
continue 


} 
if err := b.BuildStep(fmt.Sprintf("$d", stepN), line); err != nil ( 
if b.forceRm { 
b.clearTmp (b.tmpContainers) 
} 
return "", err 
) else if b.m ( 
b.clearTmp (b.tmpContainers) 
) 
stepN 4- 1 


以 上 代码 的 for 循 环 中 ， 每 一 个 循环 均 会 传 入 Dockerfile 中 的 一 行 ， 代 码 中 变量 为 line。 预 处 理 line 之 后 ， 每 次 循环 执行 的 任务 是 b.Buildstep () 函数 ， 并 在 每 一 个 循环 的 最 后 ， 对 循环 次 数 进行 统计 。 
BuildStep 函 数 的 作用 是 从 line 中 解析 相应 的 Dockerfile 指 令 ， 完 成 构建 一 个 镜像 layer 的 任务 ， 并 在 当前 上 下 文中 执行 。BuildStep 逊 数 的 定义 位 于 ./docker/docker/daemon/build.go#L921-L943， 如 下 : 


func (b *buildFile) BuildStep (name, expression string) error ( 
fmt.Fprintf(b.outStream, "Step $s : s\n", name, expression) 
tmp := strings.SplitN(expression, " ", 2) 
if len(tmp) != 2 { 
return fmt.Errorf ("Invalid Dockerfile format") 


instruction := strings.ToLower(strings.Trim(tmp[0], " ")) 
arguments := strings.Trim(tmp[1], " ") 
method, exists := reflect.TypeOf (b) .MethodByName ("Cmd" + strings. 
ToUpper(instruction[:1]) + strings.ToLower (instruction[1:])) 
if lexists { 
fmt.Fprintf(b.errStream, "f Skipping unknown instruction $sWn", 
strings.ToUpper (instruction)) 
return nil 
) 
ret := method.Func.Call([]reflect.Value(reflect.ValueOf (b), reflect. 
ValueOf (arguments) }) [0] . Interface () 
if ret !- nil ( 
return ret. (error) 
} 
fmt.Fprintf (b.outStream, " ---» %s\n", utils.TruncateID (b.image)) 
return nil 


自行 编写 过 Dockerfile 的 Docker 爱 好 者 对 于 内 部 每 一 行 的 书写 肯定 非常 清楚 。Dockerfile 的 每 一 行 都 必须 由 命令 类 型 和 命令 参数 两 部 分 构成 ， 如 : 


FROM ubuntu:14.04 

MAINTAINER Allen Sun allen.sun@daocloud.io 
RUN apt-get update 

CMD [ "/bin/bash" ] 


因此 ，Buildstep 首 先 通过 一 行 中 第 一 个 空格 字符 "将 传 入 内 容 分 离 ， 如 下 : 


tmp := strings.SplitN(expression, " ", 2) 
instruction := strings.ToLower(strings.Trim(tmp[0], " ")) 
arguments := strings.Trim(tmp[1], " ") 


数组 中 ,tmp[0] 代 表 Dockerfile 中 相应 行 的 命令 类 型 ，tmp[1] 代 表 命 令 参数 。 两 者 解析 完毕 后 ， 分 别 赋值 给 instruction 与 arguments。 命 令 类 型 获取 之 后 ，Docker Daemon 巧 妙 地 使 用 了 Golang 中 的 
反射 (reflect) 机 制 获取 具体 的 执行 方法 。 执 行 方法 提取 后 ， 执 行 时 传 入 命令 参数 ， 即 完成 了 一 条 Dockerfile 指 令 的 执行 ， 代 码 如 下 : 


method, exists := reflect.TypeOf (b).MethodByName ("Cmd" + strings. 
ToUpper(instruction[:1]) + strings.ToLower (instruction[1:])) 

ret := method.Func.Call([]reflect.Value([reflect.ValueOf (b), reflect. 
ValueOf (arguments) }) [0] . Interface () 


对 于 Dockerfile 内 的 每 一 条 命令 ，Docker Daemon 都 会 执行 一 次 循环 并 通过 反射 完成 方法 的 执行 。 如 Dockerfile 中 的 命令 FROM ubuntu: 14.04， 首 先 可 以 解析 出 命令 类 型 为 FROM ， 命 令 参 数 为 
ubuntu: 14.04， 即 instruction 值 为 rom，arguments 为 ubuntu: 14.04; 接着 反射 机 制 将 通过 字符 串 “CmdFrom” 找 到 方法 CmdFrom， 即 method 为 CmdFrom; 最 后 通过 method.Func.Call () && 
数 传 入 参数 ， 完 成 命令 的 执行 。 


11.4 节 将 分 析 Dockerfile 内 具体 命令 的 执行 。 


11.4 ”Dockerfile 命 令 分 析 


众所周知 ，Docker Daemon 在 构建 Dockerfile 的 过 程 中 ， 对 Dockerfile 中 的 每 一 条 命令 (FROM 命 令 除 外 ) 都 会 构建 一 个 新 的 mage。 因 此 ， 围 绕 Docker 的 镜像 技术 ，build 的 流程 也 是 创建 一 个 个 


image 的 过 程 。 


对 于 一 个 Dockerfile, 或 者 Dockerfile 内 的 一 条 或 多 条 命令 ，buildFile 对 象 均 完美 地 记录 所 有 命令 执行 时 的 上 下 文 现状 。 


Dockerfile 内 部 的 命令 简单 ， 可 以 分 为 两 类 。 第 一 类 命令 修改 上 一 层 image 的 文件 系统 内 容 ， 比 如 : 命令 RUN 在 基于 上 一 层 image 的 容器 中 运行 一 条 指令 ， 对 于 用 户 而 言 ， 该 指令 很 有 可 能 修改 上 一 层 
image 的 内 容 ; 命令 ADD 在 Dockerfile 所 在 目录 的 context 中 复制 内 容 至 上 一 层 image， 用 户 视角 下 同样 属于 修改 镜像 ;这样 的 命令 还 有 COPY 等 。 第 二 类 命令 仅仅 修改 镜像 的 config 信 息 ， 比 如 : 命令 ENV 
不 会 修改 镜像 文件 系统 中 的 内 容 ， 而 仅仅 修改 镜像 的 config 的 ENV 信 息 ， 以 便 后 续 使 用 该 镜像 启动 进程 时 ，ENV 信 息 作为 进程 的 环境 变量 加 载 ， 同样 EXPOSE 命 令 代表 以 该 镜像 运行 容器 时 ， 容 器 内 进程 会 
监听 EXPOSE 的 端口 号 ， 以 便 Docker Daemon 捕 获 容器 内 的 端口 监听 情况 ， 这 部 分 信息 同样 会 被 记录 至 config 信 息 ， 最 后 被 更 新 至 镜像 的 json 文 件 中 ; 第 二 类 命令 还 包括 很 多 ， 如 CMD、ENTRYPOINT、 
MAINTAINER 等 。 


本 节 着 重 分 析 三 种 具有 代表 性 的 Dockerfile 命 令 FROM、RUN、ENV， 阐 述 这 些 命令 解析 执行 时 ， 构 建 Docker 新 镜像 的 详细 过 程 。 


11.5 总结 


心口 


Dockerfile build 的 流程 是 不 断 创 建新 镜像 的 过 程 。 有 的 镜像 包含 文件 系统 的 内 容 ， 这 意味 着 镜像 创建 过 程 中 ， 容 器 的 Read-Write 层 被 修改 ;， 有 的 镜像 内 容 为 空 ， 即 不 包含 文件 系统 的 内 容 ， 这 意味 着 
镜像 创建 过 程 中 ， 仪 仅 修改 了 镜像 的 json 信 息 。 


Dockerfile 的 存在 ， 使 得 软件 有 能 力 与 运行 环境 一 同 以 一 种 非常 轻 量 级 的 方式 分 发 。 不 论 是 软件 的 发 布 ， 还 是 软件 的 管理 方面 ，Dockerfile 都 大 大 释放 了 软件 的 生命 力 。 本 章 即 从 docker build 的 流程 入 
手 ， 从 原理 的 角度 分 析 了 构建 镜像 的 全 过 程 。 熟 悉 docker build 的 流程 ， 对 于 编写 高 效 、 合 理 的 Dockerfile， 具 有 非常 大 的 帮助 。 


第 12 章 ”Docker 容 器 创建 


12.1 引言 


云 计 算 时 代 ， 随 着 Docker 的 异军突起 ， 工 业界 刊 过 阵 阵容 器 的 飓风 。 由 风 所 到 之 处 ， 圈 内 人 士 纷纷 探讨 Docker 与 传统 虚拟 化 技术 的 异同 。 传 统 的 虚拟 化 技术 ， 如 KVM、Xen 等 ， 在 过 去 的 数 年 间 已 经 
受到 行业 的 检验 ， 虽 然 不 是 尽善尽美 ， 但 给 工业 界 带 来 的 好 处 也 足以 让 世人 对 其 称赞 。Docker 的 诞生 并 不 是 为 了 蔡 代 传统 的 虚拟 化 技术 ， 然 而 ， 它 的 诞生 却 让 人 如 拿 着 放大 镜 般 地 看 待 传统 虚拟 化 技术 的 浆 


病 。 可 以 说 ，Docker 指 明了 又 一 条 虚拟 化 道路 ; 或 许 阅 Docker 拓 宽 了 虚拟 化 的 范畴 。 传 统 的 虚拟 化 技术 主要 用 于 提供 基础 设施 的 服务 ， 而 Docker 在 隔离 与 控制 计算 资源 的 同时 仍然 可 以 融入 用 户 的 应 用 罗 
辑 ， 基 础 设施 和 上 层 应 用 的 界限 被 打破 。 存 在 即 合理 ， 风 摩 全 球 更 说 明了 Docker 满 足 了 用 户 以 往 那 些 被 认为 天 方 夜 谭 的 需求 。 


一 直 认 为 Docker 可 以 提供 “容器 ”服务 ， 正 是 Docker 提 供 的 “容器 ”会 经 常用 来 与 “虚拟 机 ”比较 。 很 多 比较 的 维度 大 家 肯定 不 陌生 ， 比 如 : “容器 ”运行 时 与 宿主 机 共享 同一 个 操作 系统 ， 节 省 物 
理 资源 ; “容器 ”的 启动 非常 快 ， 甚 至 可 以 达到 秒 级 ，“ 容 器 ”运行 时 VO 性 能 明显 高 于 虚拟 机 .…… 工 业界 对 两 者 的 比较 肯定 比 以 上 罗列 的 更 全 面 、 更 具体 。 然 而 ， 似 乎 很 多 观点 都 和 “容器 ”的 运行 息 息 相 
关 。 而 “容器 ”的 运行 到 底 是 何 种 情况 ?本 章 将 以 Docker 为 例 ， 展 现 Docker 容 器 运行 的 始末 。 


本 章 主要 从 源码 的 角度 分 析 用 户 发 起 docker run 命 令 之 后 ， 整 个 Docker 体 系 中 的 组 件 如 何 协同 工作 ， 最 终 实现 Docker 容 器 的 运行 。 本 书 的 分 析 均 基于 Docker 1.2.0 版 本 ，libcontainer 的 版 本 也 为 
1.2.0。 本 章 主要 内 容 包含 以 下 三 个 方面 : 


1) 简要 讲述 Docker 容 器 运行 的 流程 ， 即 从 Docker Client, Docker Server 以 及 Docker Daemon 的 角度 阐述 docker run 命 令 的 执行 流程 ; 


2) 详细 分 析 Docker Daemon 创 建 容器 对 象 的 过 程 ; 


3) 详细 分 析 Docker Daemon 启 动容 器 的 过 程 。 


第 12 章 ”Docker 容 器 创建 


12.1 引言 


云 计 算 时 代 ， 随 着 Docker 的 异军突起 ， 工 业界 刊 过 阵 阵容 器 的 刚 风 。 飓 风 所 到 之 处 ， 圈 内 人 士 纷 纷 探讨 Docker 与 传统 虚拟 化 技术 的 异同 。 传 统 的 虚拟 化 技术 ， 如 KVM、Xen 等 ， 在 过 去 的 数 年 间 已 经 
受到 行业 的 检验 ， 虽然 不 是 尽善尽美 ， 但 给 工业 界 带 来 的 好 处 也 足以 让 世人 对 其 称赞 。Docker 的 诞生 并 不 是 为 了 替代 传统 的 虚拟 化 技术 ， 然 而 ， 它 的 诞生 却 让 人 如 拿 着 放大 镜 般 地 看 待 传统 虚拟 化 技术 的 并 


病 。 可 以 说 ，Docker 指 明了 又 一 条 虚拟 化 道路 ; 或 许 说 Docker 拓 宽 了 虚拟 化 的 范畴 。 传 统 的 虚拟 化 技术 主要 用 于 提供 基础 设施 的 服务 ， 而 Docker 在 隔离 与 控制 计算 资源 的 同时 仍然 可 以 融入 用 户 的 应 用 多 
辑 ， 基 础 设施 和 上 层 应 用 的 界限 被 打破 。 存 在 即 合理 ， 风 摩 全 球 更 说 明了 Docker 满 足 了 用 户 以 往 那 些 被 认为 天 方 夜 谭 的 需求 。 


一 直 认 为 Docker 可 以 提供 “容器 ”服务 ， 正 是 Docker 提 供 的 “容器 ”会 经 常用 来 与 “虚拟 机 ”比较 。 很 多 比较 的 维度 大 家 肯定 不 陌生 ， 比 如 : “容器 ”运行 时 与 宿主 机 共享 同一 个 操作 系统 ， 节 省 物 
理 资源 ; “容器 ”的 启动 非常 快 ， 甚 至 可 以 达到 秒 级 ，“ 容 器 ”运行 时 |/O 性 能 明显 高 于 虚拟 机 .….. 工 业界 对 两 者 的 比较 肯定 比 以 上 罗列 的 更 全 面 、 更 具体 。 然 而 ， 似 乎 很 多 观点 都 和 “容器 ”的 运行 息 息 相 
关 。 而 “容器 ”的 运行 到 底 是 何 种 情况 ?本 章 将 以 Docker 为 例 ， 展 现 Docker 容 器 运行 的 始末 。 


本 章 主要 从 源码 的 角度 分 析 用 户 发 起 docker run 命 令 之 后 ， 整 个 Docker 体 系 中 的 组 件 如 何 协同 工作 ， 最 终 实现 Docker 容 器 的 运行 。 本 书 的 分 析 均 基于 Docker 1.2.0 版 本 ，libcontainer 的 版 本 也 为 
1.2.0。 本 章 主要 内 容 包含 以 下 三 个 方面 : 


1) 简要 讲述 Docker 容 器 运行 的 流程 ， 即 从 Docker Client, Docker Server 以 及 Docker Daemon 的 角度 阐述 docker run 命 令 的 执行 流程 ; 


2) 详细 分 析 Docker Daemon 创 建 容器 对 象 的 过 程 ; 


3) 详细 分 析 Docker Daemon 启 动容 器 的 过 程 。 


12.2 “Docker 容 器 运行 流程 


一 位 精通 Docker 的 好 手 ， 对 于 docker run 命 令 的 使 用 绝对 了 然 于 胸 。 此 命令 帮助 Docker 用 户 在 指定 配置 下 完成 Docker 容 器 的 运行 ， 并 运行 用 户 指定 的 程序 。Docker 架 构 中 ， 几 乎 所 有 的 操作 均 与 
docker run 有 莫大 的 关联 。 镜 像 下 拉 命 令 docker pull， 目 标 正 是 通过 docker run 命 令 在 镜像 的 基础 上 运行 容器 ; 镜像 构建 命令 docker build， 一 旦 Dockerfile 中 涉及 RUN 命 令 ， 每 执行 一 个 RUN 命 令 , 均 
会 运行 一 个 Docker 容 器 ， 并 对 容器 进行 commit 操 作 ， 打 包容 器 镜像 ;而 Docker 中 设置 网 络 模式 、 容 器 互联 (link) 等 操作 ， 均 需要 在 容器 运行 前 给 docker run 命 令 指 定 参数 。 


网 


如 图 12-1 所 示 


命令 docker run 与 其 他 命令 无 差别 ,执行 流程 均 由 Docker Client, Docker Server 以 及 Docker Server 协 同 完成 。 第 7 章 分 析 Docker 容 器 的 网 络 时 曾 分 析 过 此 执行 流程 ， 此 流程 


Rp*e 


(Docker Server 仅 负责 路 由 转发 ， 图 中 并 未 显著 标 出 ) : 


Docker Client 


parse config, 
hostConfig, cmd 


create container 
(with config) 


pull image 


start container 


(with hostCofig) 


图 12-1 表 明 ，Docker Client 共 发 送 了 两 次 POST 请 求 至 Dock 
使 得 容器 处 于 运行 状态 。 对 于 Docker Client 而 言 ，docker run 命 
的 两 个 数据 结构 config 与 hostconfig， 来 存储 所 有 命令 参数 。 关 于 
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图 12-1 docker run 命 令 执 行 流程 


er Daemon。 第 一 次 请 求 试图 让 Docker Daemon 通 过 请 求 中 的 镜像 信息 ， 创 建 容 器 对 象 ; 第 二 次 请 求 则 通知 Docker Daemon 启 动容 器 ， 
令 的 所 有 参数 都 需要 处 理 成 Docker Daemon 可 以 识别 的 形式 ， 为 此 Docker 的 设计 者 设计 了 Docker Client&Docker Daemon 均 可 以 识别 


Fconfig 结 构 体 与 hostconfig 结 构 体 的 描述 与 分 析 ， 可 以 参见 7.3.2 节 。 


为 了 阐述 清楚 config 与 hostconfig 中 包含 的 参数 信息 ， 本 章 使 用 以 下 docker run 命 令 进行 举例 分 析 : 


docker run -m 104857600 -P --net-bridge -v /home/test:/home/test -v /data -e TEST ENV-myenv --name ubuntu test --link db:db ubuntu:14.04 


以 上 命令 中 参数 的 分 析 如 表 12-1 所 示 。 


参数 名 称 参数 形式 
-m -m 104857600 


1 
"d 


--net --net-bridge 


表 12-1 docker run 命 令 参 数 解析 
为 容器 运行 设置 内 存 上 限 104857600 字 节 ， 即 100MB 
将 容器 内 EXPOSE 的 端口 均 暴 露 至 宿主 机 
容器 运行 时 使 用 bridge (桥接 ) 网 络 模式 


-V -y /home/test:/home/test 将 宿主 机 目录 /home/test 挂 载 至 容器 的 /home'/test 


-V /data 


HA AEAEE EHER (bind-mount) 的 data volume /data 


-e —e TEST_ENV=myenv 为 容器 添加 环境 变量 TEST_ENV， 值 为 myenv 


--name --name ubuntu test 
--link --link db:db 


为 容器 设置 名 称 ubuntu test 
将 容器 db 以 别名 db 的 形式 链接 到 创建 的 容器 中 


Docker Client 的 参数 解析 工作 是 : 处 理 类 似 以 上 的 参数 并 存 入 config 或 者 hostconfig， 最 后 分 别 通 过 两 次 POST 请 求 发 送 至 Docker Daemon, Docker Client 与 Docker Server 解 析 处 理 请 求 的 分 析 ， 
本 章 已 经 提 及 过 ， 故 不 再 乾 述 。 本 章 仅 从 Docker Daemon 两 次 处 理 并 响应 POST 请 求 入 手 ， 还 原 Docker 容 器 运行 的 现场 。 


12.3 Docker Daemon 创建 容器 对 象 


Docker 容 器 的 运行 并 非 只 是 简单 地 调用 内 核 接口 ，Docker 的 设计 者 有 意 将 配置 信息 与 启动 容器 的 操作 进行 区 分 ， 实 现 数据 与 逻辑 的 有 机 分 离 。 


Docker 用 户 指定 的 众多 参数 ， 以 及 Docker 镜 像 中 的 众多 参数 ， 在 运行 容器 时 ， 均 可 以 认为 是 Docker 容 器 的 配置 信息 来 源 。 当 第 一 次 接收 到 Docker Client 发 送 的 POST 请 求 后 ，Docker Daemon 开 始 
创建 容器 对 象 container， 处 理 并 整理 用 户 指定 与 镜像 指定 的 config 信 息 。 创 建 container 对 象 的 源码 实现 位 于 ./docker/dockervdaemony/create.go#L56-L186， 如 下 : 


// Create creates a new container from the given configuration with a given name. 
func (daemon *Daemon) Create(config *runconfig.Config, name string) (*Container, []string, error) ( 
var ( 
container *Container 


warnings  []string 
) 
img, err := daemon.repositories.LookuplImage (config.Image) 
if err !- nil ( 


return nil, nil, err 

} 

if err := img.CheckDepth(); err != nil { 
return nil, nil, err 

} 

if warnings, err = daemon.mergeAndVerifyConfig(config, img); err != nil { 
return nil, nil, err 


if container, err = daemon.newContainer(name, config, img); err !- nil ( 
return nil, nil, err 


if err := daemon.createRootfs (container, img); err != nil ( 
return nil, nil, err 

) 

if err ;= container.ToDisk(); err != nil 1 
return nil, nil, err 

$ 

if err := daemon.Register (container); err != nil { 
return nil, nil, err 

} 


return container, warnings, nil 


Create 函 数 的 逻辑 极其 清晰 ， 从 起 初 声明 container 对 象 ， 到 最 后 返回 container， 中 间 环 节 的 逻辑 完全 属于 顺序 执行 。 表 12-2 给 出 了 中 间 各 环节 执行 的 函数 与 作用 。 


表 12-2 Create 函数 执行 步骤 解析 
执行 函数 名 称 执行 函数 作用 
LookupImage 在 daemon 对 象 的 repositories 属性 中 查找 用 户 指 定 镜像 
CheckDepth 检验 镜像 的 layer 总 数 ， 镜 像 层 总 数 不 能 超过 127 
mergeAndVerifyConfig 将 用 户 指定 的 config 参数 与 镜像 json 文件 中 的 config 合并 并 验证 


newContainer 创建 新 的 container 对 象 

createRootfs 创建 属于 container 对 象 的 rootfs 

ToDisk 将 container 对 象 json 化 之 后 写 人 本 地 磁盘 进行 持久 化 
Register É Docker Daemon 中 注册 该 新 建 的 container XJ 


12.4 Docker Daemon 启 动容 器 


Docker 的 世界 中 ， 动 态 的 内 容 往往 更 加 迷人 。 静 态 的 内 容 ， 诸 如 镜像 、Dockerfile、Docker Registry 等 ， 似 乎 都 是 为 了 服务 于 动态 的 容器 。12.3 节 中 的 container 对 象 的 创建 ， 也 仅仅 是 静态 内 容 的 梳 
理 与 组 织 ， 仍 缺少 容器 方面 的 活力 。 


Docker Daemon 启 动容 器 的 操作 取决 于 docker run 命 令 发 起 的 第 一 个 POST 请 求 。 由 于 container 对 象 已 经 创建 ， 并 由 daemon 对 象 管理 ， 故 POST 请 求 只 要 携带 container 的 ID 信息 ， 容 器 启动 命令 就 
能 触发 。 


从 逻辑 的 角度 而 言 ，Docker Daemon 仅 仅 通过 获取 container 对 象 ， 并 执行 此 对 象 的 Start 函 数 。 从 start 函 数 的 具体 执行 内 容 而 言 ， 涉 及 的 内 容 很 广泛 ， 图 12-3 详 细 说 明 Docker Daemon 针 对 


container 对 象 所 操作 的 具体 内 容 。 
Daemon ENV network 
container linked ENV 
volumes aj 


Container 


- 


data volume 
bind mount 


12-3 Start Zt Sp LA E 


就 顺序 而 言 ，Docker Daemon 执 行 Sstart 函 数 ， 包 含 以 下 11 个 步骤 。 


12.5 ”总结 


Docker 容 器 的 启动 ， 意 味 着 用 户 运行 时 的 开始 。 对 于 Docker 用 户 而 言 ， 仪 仅 能 感受 到 自身 应 用 的 正常 运行 。 然 而 ， 对 于 Docker Daemon 而 言 ， 需 要 完成 的 工作 要 远 比 这 复杂 ， 从 最 初 的 镜像 查找 ， 到 
rootfs 配 备 ， 还 有 网 络 、volume、 容 器 link 等 配置 信息 的 收集 ， 以 及 最 后 启动 代表 容器 主 进程 的 Command 命 令 。 


Docker 体 系 内 的 万 干 概念 ， 最 后 都 融 汇 在 代表 容器 主 进程 的 Command 命 令 中 ， 且 最 终 体现 在 主 进程 的 启动 流程 中 。 本 章 从 Docker 容 器 的 创建 入 手 ， 着 重 分 析 了 Docker Daemon 的 启动 全 过 程 。 


第 13 章 dockerinit 启 动 


13.1 引言 


Docker 容 器 作为 Docker Daemon 管 理 的 对 象 ， 给 用 户 的 体验 是 一 个 隔离 性 较 好 的 运行 环境 。 作 为 容器 技术 ， 隔 离 环境 背后 的 技术 支撑 是 什么 ”Docker 容 器 可 以 运行 用 户 应 用 进程 ， 容 器 与 进程 的 关系 
又 如 何 ? 可 以 说 ,认识 Docker 是 一 条 漫长 的 路 ， 在 这 条 路 上 ， 仍 然 存 在 不 少 疑惑 。 


为 阐述 Docker 容 器 与 进程 的 关系 ， 首 先 以 用 户 都 见 过 的 docker run 命 令 为 例 。 通 过 Docker 容 器 完成 指定 应 用 进程 的 运行 ， 相 信 所 有 的 Docker 用 户 都 不 陌生 ， 然 而 ， 应 用 进程 是 否 是 容器 内 的 第 一 个 进 
程 ， 一 旦 提 及 这 一 点 ， 也 会 激 起 Docker 用 户 心中 的 疑惑 。 虽 然 第 7 章 已 经 对 容器 与 进程 的 关系 进行 了 初步 的 介绍 与 分 析 ， 但 是 关于 容器 内 第 一 个 进程 究竟 为 何方 神圣 ， 依 然 没 有 揭 开 神秘 的 面纱 。 开 门 见 
山 ，Docker Daemon 启 动 Docker 容 器 时 ， 运 行 的 第 一 个 进程 并 不 是 用 户 的 应 用 进程 ， 而 是 一 个 称 为 dockerinit 的 进程 。 


本 章 主 要 从 源码 的 角度 介绍 dockerinit， 并 分 析 dockerinit 启 动 流程 的 实现 。 本 书 基于 Docker 1.2.0 版 本 ，libcontainer 的 版 本 为 1.2.0。 本 章 内 容 主要 包含 以 下 4 个 方面 : 


1) 简要 介绍 dockerinit; 


a 


2) 分 析 dockerinit 的 执行 入 
3) 分 析 dockerinit 的 运行 ; 


4) 分 析 libcontainer 的 运行 。 
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Docker 容 器 作为 Docker Daemon 管 理 的 对 象 ， 给 用 户 的 体验 是 一 个 隔离 性 较 好 的 运行 环境 。 作 为 容器 技术 ， 隔 离 环境 背后 的 技术 支撑 是 什么 ”Docker 容 器 可 以 运行 用 户 应 用 进程 ， 容 器 与 进程 的 关系 
又 如 何 ? 可 以 说 ,认识 Docker 是 一 条 漫长 的 路 ， 在 这 条 路 上 ， 仍 然 存 在 不 少 疑惑 。 


为 阐述 Docker 容 器 与 进程 的 关系 ， 首 先 以 用 户 都 见 过 的 docker run 命 令 为 例 。 通 过 Docker 容 器 完成 指定 应 用 进程 的 运行 ， 相 信 所 有 的 Docker 用 户 都 不 陌生 ， 然 而 ， 应 用 进程 是 否 是 容器 内 的 第 一 个 进 
程 ， 一 旦 提 及 这 一 点 ， 也 会 激 起 Docker 用 户 心中 的 疑惑 。 虽 然 第 7 章 已 经 对 容器 与 进程 的 关系 进行 了 初步 的 介绍 与 分 析 ， 但 是 关于 容器 内 第 一 个 进程 究竟 为 何方 神圣 ， 依 然 没 有 揭 开 神秘 的 面纱 。 开 门 见 
山 ，Docker Daemon 启 动 Docker 容 器 时 ， 运 行 的 第 一 个 进程 并 不 是 用 户 的 应 用 进程 ， 而 是 一 个 称 为 dockerinit 的 进程 。 


本 章 主 要 从 源码 的 角度 介绍 dockerinit， 并 分 析 dockerinit 启 动 流程 的 实现 。 本 书 基于 Docker 1.2.0 版 本 ，libcontainer 的 版 本 为 1.2.0。 本 章 内 容 主要 包含 以 下 4 个 方面 : 


1) 简要 介绍 dockerinit; 


2) 分 析 dockerinit 的 执行 入 口 ; 
3) 分 析 dockerinit 的 运行 ; 


4) 分 析 libcontainer 的 运行 。 


13.2 dockerinit 介 绍 


正如 其 名 ， 可 以 认为 dockerinit 是 Docker 容 器 中 的 init 进 程 。Linux 操 作 系统 中 ，init 进 程 是 一 个 非常 重要 的 进程 ， 它 负责 初始 化 系统 ， 并 且 是 所 有 用 户 进程 的 祖先 进程 。 相 同 的 概念 ， 在 Docker 容 器 中 
也 有 很 好 的 体现 ，dockerinit 作 为 Docker 容 器 中 的 第 一 个 进程 ， 同 样 扮演 初始 化 容器 的 角色 ， 同 样 是 Docker 容 器 内 所 有 进程 的 祖先 进程 。 


13.3 ” dockerinit 执 行 入 口 


第 12 章 主要 分 析 Docker 容 器 的 创建 ， 然 而 ， 关 于 Docker Daemon 启 动容 器 ， 分 析 到 创建 monitor 对 象 并 监控 容器 的 启动 之 后 ， 却 并 未 再 深入 。 若 继续 深究 ， 我 们 则 可 以 发 现 程序 的 执行 将 从 Docker 


Daemon 转 移 至 execdriver， 最 终 进 入 libcontainer。 


寻找 dockerinit 的 诞生 ， 必 须 追 逆 到 execdriver。Docker Daemon 启 动容 器 的 参数 ， 最 终 需要 libcontainer 来 加 载 ， 而 execdriver 负 责 将 Docker Daemon 描 述 容 器 的 container 对 象 转 义 ， 使 其 符合 
libcontainer 的 接口 。 在 这 样 的 过 程 中 ，execdriver 调 用 libcontainer 的 namespace 包 时 ， 将 dockerinit 作 为 参数 传递 至 libcontainer。 调 用 函数 的 定义 位 于 libcontainer 项 目的 namespace 包 中 ， 函 数 名 为 
exec， 源 码 实现 位 于 ./docker/libcontainer/namespaces/exec.go#L24， 如 下 : 


func Exec(container *libcontainer.Config, stdin io.Reader, stdout, stderr io.Writer, console string, rootfs, dataPath string, args []string, createCommand CreateCommand, startC 


13.4 dockerinit 运 行 


dockerinit 作 为 Docker 容 器 中 运行 的 第 一 个 进程 ， 本 质 上 ， 它 是 一 个 使 用 go 语言 编译 的 可 执行 文件 ， 即 dockerinit-1.2.0。 既 然 如 此 ， 回 到 dockerinit 的 实现 函数 ， 可 以 发 现 dockerinit 的 实现 全 部 依靠 
reexec.Init () 函数 。dockerinit 的 main 函 数位 于 ./docker/docker/dockerinit/dockernit.go#L9-L12， 如 下 : 


func main() { 
// Running in init mode 
reexec.Init() 


以 上 代码 简洁 得 有 点 极致 ，main 通 过 reexec.Init () 来 实现 。 是 否 reexec.Init () 真 的 实现 了 对 容器 环境 的 初始 化 ?让 我 们 带 着 疑惑 进入 reexec.Init () 的 分 析 。 


13.5 libcontainer 的 运行 


libcontainer 是 一 套 容器 技术 的 实现 方案 ， 借 助 于 libcontainer 的 调用 ， 可 以 完成 容器 的 创建 与 管理 。dockerinit 就 通过 libcontainer 来 完成 容器 的 创建 与 初始 化 。 


dockerinit 通 过 namespaces 包 的 Init 函 数 来 调用 libcontainer 的 API 接 口 并 完成 所 有 工作 ， 但 是 Init 完 成 的 内 容 绝 不 仅仅 只 有 与 Linux namespace 相 关 的 内 容 。lnit 是 全 新 namespace 下 运行 的 第 一 部 分 
内 容 ， 同 时 会 完成 mount 信 息 、 容 器 用 户 以 及 网 络 等 多 方面 的 配置 。 


Ej 


由 于 dockerinit 需 要 与 Docker Daemon 进 行 信息 同步 ， 故 几乎 可 以 将 这 父子 进程 的 管道 同步 作为 一 个 分 水 岭 ， 前 半 部 分 作为 进程 的 配置 ， 后 半 部 作为 初始 化 容器 的 资源 。Init 函 数 的 实现 位 
于 ./docker/libcontainer/namespaces/init.go#L32-L122， 如 下 : 


func Init(container *libcontainer.Config, uncleanRootfs, consolePath string, syncPipe *syncpipe.SyncPipe, args []string) (err error) ( 


if err := LoadContainerEnvironment (container); err != nil ( 
return err 
} 
// We always read this as it is a way to sync with the parent as well 
Var networkState *network.NetworkState 
if err := syncPipe.ReadFromParent (&networkState); err != nil { 
return err 


if err := setupNetwork(container, networkState); err !- nil ( 
return fmt.Errorf ("setup networking $s", err) 


if err := mount.InitializeMountNamespace (rootfs, 
consolePath, 
container.RestrictSys, 
(*mount.MountConfig) (container.MountConfig)); err !- nil { 
return fmt.Errorf ("setup mount namespace $s", err) 


if err := FinalizeNamespace (container); err !- nil ( 
return fmt.Errorf("finalize namespace $s", err) 


// FinalizeNamespace can change user/group which clears the parent death 
// signal, so we restore it here. 
if err := RestoreParentDeathSignal(pdeathSignal); err !- nil ( 
return fmt.Errorf("restore parent death signal $s", err) 
} 


return system.Execv (args[0], args[0:], os.Environ()) 


dockerinit 通 过 向 syncPipe 读 取 父 进程 Docker Daemon 传 递 的 内 容 ， 完 成 两 者 信息 的 同步 。Docker Daemon 与 dockerinit 的 同步 流程 如 图 13-1 所 示 。 
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图 13-1 Docker Daemon 与 docketinit 的 同步 流程 


通过 图 13-1 我 们 可 以 发 现 ，Docker Daemon 通 过 libcontainer 中 namespaces 包 的 exec 函 数 执行 Command.Start () 之 后 ， 仍 有 其 他 的 工作 需要 完成 ， 主 要 工作 如 下 : 


网 


1) SetupCgroups， 设 置 dockerinit 进 程 的 cgroups， 完 成 dockerinit 进 程 的 资源 限制 ; 
2) InitializeNetworking， 创 建 dockerinit 所 在 容器 的 网 络 栈 资源 ; 
3) syncPipe.ReadFromChild， 与 子 进 程 dockerinit 同 步 。 


回 到 Docker Daemon 的 namespaces.Exec 中 ， 下 面 分 析 执 行 流程 


13.6 总 结 


7 一口 


深入 学 习 dockerinit 的 原理 ， 对 于 理解 Docker 容 器 的 实现 会 有 很 大 帮助 。 若 对 dockerinit 思 考 得 更 多 ， 则 可 以 发 现 dockerinit 的 启动 ， 即 Docker 容 器 的 启动 ， 完 全 是 借助 Linux 内 核 的 众多 特性 在 做 工 
作 。 从 Linux 内 核 的 角度 来 看 待 Docker 容 器 ， 容 器 技术 的 实现 手段 并 非 深 不 可 测 ， 容 器 毕竟 和 宿主 机 共享 同一 个 Linux 内 核 ， 所 有 工作 都 通过 内 核 来 完成 。 


Docker 容 器 的 成 功 创建 ， 可 以 说 是 Docker Daemon 与 dockerinit 协 同 合作 的 结果 。Docker Daemon 创 建 一 个 初步 的 容器 环境 ， 并 将 容器 环境 的 初始 化 工作 交 给 dockerinit 来 完成 ， 同 时 两 者 之 间 完 成 
起 码 的 通信 。dockerinit 的 运行 起 到 一 个 承前启后 的 作用 ， 它 不 仅 接受 Docker Daemon 的 使 命 ， 完 成 容器 环境 的 初始 化 ， 同 时 还 负责 将 容器 的 运行 转变 为 用 户 应 用 程序 Cmd 的 运行 ， 并 将 容器 交付 给 
Docker 用 户 。 
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141 引言 


在 Docker 圈 ， 大 家 也 许 听 说 过 这 样 类 似 于 这 样 的 话 “Docker 的 本 质 并 非 是 新 颖 的 技术 ， 容 器 技术 也 早已 诞生 多 年 ”。 可 以 说 ， 此 言 没有 半点 夸大 。 在 Docker 之 前 ，Linux 平 台 上 以 LXC 为 代表 的 一 系列 
容器 技术 早已 在 历史 舞台 上 活跃 多 年 。 对 于 包括 Docker 在 内 的 多 种 容器 技术 ， 最 终 的 容器 都 离 不 开 Linux 内 核 的 很 多 高 级 特性 ， 如 : namespace、cgroup 等 。 


Docker 架 构 中 ，Docker Daemon 作 为 一 个 常 驻 进程 ， 管 理 Docker Client 请 求 的 同时 ， 还 管理 所 有 的 Docker 容 器 。 而 Linux 操 作 系统 内 核 态 对 容器 的 管理 ， 自 然 需要 为 用 户 态 的 Docker Daemon 服 
务 ， 因 此 如 果 在 Docker Daemon 与 Linux 内 核 之 间 有 一 套 完善 的 API 接 口 ， 那 么 两 者 的 衔接 将 变 得 尤为 顺畅 。Docker 的 发 展 历程 中 ，0.9.0 版 本 即 引 入 了 libcontainer 模 块 ， 这 意味 着 内 核 API 接 口 的 横 空 出 


简单 而 言 ，libcontainer 是 一 套 实现 容器 管理 的 Go 语言 解决 方案 。 这 套 解决 方案 实现 过 程 中 使 用 了 Linux 内 核 特 性 namespace 与 cgroup， 同 时 还 采用 了 capability 与 文件 权限 控制 等 其 他 一 系列 技术 。 


基于 这 些 特性 ， 除 了 创建 容器 之 外 ，libcontainer 还 可 以 完成 管理 容器 生命 周期 的 任务 。 


Docker 容 器 提供 一 个 隔离 、 独 立 的 环境 ， 毫 不 过 分 地 说 ， 这 样 的 效果 完全 离 不 开 libcontainer 的 功劳 。 隔 离 的 效果 自然 是 容器 内 部 与 容器 外 部 的 隔离 ， 然 而 ， 对 于 实现 此 功能 的 libcontainer 而 言 ， 需 要 
完成 的 工作 正 像 容 器 内 外 一 样 ， 既 需要 在 容器 外 做 容器 的 配置 与 管理 ， 同 时 还 需要 在 容器 内 部 完成 相应 的 初始 化 工作 。 


另外 ， 需 要 提 及 的 是 ，libcontainer 作 为 一 个 提供 内 核 API 接 口 的 容器 技术 解决 方案 ， 设 计 之 初 就 以 简洁 方便 为 目的 ， 以 至 于 libcontainer 的 生成 与 运行 没有 任何 依赖 。 作 为 纯粹 并 且 接 口 完 备 的 容器 管 
理工 具 ，libcontainer 似 乎 有 反 向 定义 Linux 容 器 技术 的 含义 ， 尝 试 成 为 容器 技术 的 新 生 标准 。 同 时 ，libcontainer 的 设计 似乎 也 让 开发 者 看 到 了 Docker 跨 平台 的 潜在 能 力 。Docker Daemon 负 责 Docker 
Server 的 一 系列 API 接 口 ， 而 libcontainer 接 管 Linux 平 台 内 核 态 容器 技术 实现 的 API 接 口 ， 两 者 通过 execdriver 的 形式 协调 工作 。 如 此 一 来 ， 在 原 有 Docker server 的 API 接 口 下 ， 似 乎 蔡 换 其 他 平台 的 底层 容 
器 实现 技术 的 接口 即 可 ， 如 在 Solaris 操 作 系统 下 ， 开 发 一 个 类 似 于 libcontainer 的 库 ， 兼 容 Docker Daemon 的 API 接 口 ， 而 实现 Solaris 的 底层 容器 技术 。 因 此 ，Docker 今 后 在 跨 平 台 方 面 的 能 力 绝 不 可 低 
估 。 
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Server 的 一 系列 API 接 口 ， 而 libcontainer 接 管 Linux 平 台 内 核 态 容器 技术 实现 的 API 接 口 ， 两 者 通过 execdriver 的 形式 协调 工作 。 如 此 一 来 ， 在 原 有 Docker server 的 API 接 口 下 ， 似 乎 蔡 换 其 他 平台 的 底层 容 
器 实现 技术 的 接口 即 可 ， 如 在 Solaris 操 作 系统 下 ， 开 发 一 个 类 似 于 libcontainer 的 库 ， 兼 容 Docker Daemon 的 API 接 口 ， 而 实现 Solaris 的 底层 容器 技术 。 因 此 ，Docker 今 后 在 跨 平 台 方 面 的 能 力 绝 不 可 低 
估 。 


14.2 Docker、libcontainer 以 及 LXC 的 关系 


Docker 的 热潮 席卷 全 球 ， 没 有 适应 于 如 此 节奏 的 技术 爱好 者 ,或 者 曾 在 类 似 于 LXC 技 术 方面 有 所 研究 的 开发 者 ， 肯 定 会 如 此 发 问 : Docker 与 LXC 的 区 别 到 底 在 哪里 ? 


从 底层 技术 栈 而 言 ， 似 乎 区 别 不 大 ，Linux 的 内 核 特 性 不 仅 LXC 可 以 使 用 ，Docker 可 以 使 用 ， 而 且 任何 第 三 方 的 容器 技术 提供 商 均 可 以 基于 此 进行 开发 。 


从 软件 生命 周期 来 讲 ， 两 者 则 存在 很 大 的 差异 。Docker 可 以 这 样 认为 : 一 个 Docker Daemon 管 理 众多 的 容器 ，Docker Daemon 为 常 驻 的 后 台 进程 。 而 LXC 则 是 一 个 工具 ， 装 有 LXC 的 宿主 机 上 并 没有 
一 个 与 LXC 相 关 的 常 驻 进程 在 后 台 运行 。 当 用 户 发 起 与 容器 相关 的 创建 与 管理 命令 后 ，LXC 以 进程 的 形式 来 处 理 命令 ， 命 令 完 成 后 进程 立即 退出 。 


既然 Docker 最 终 也 需要 创建 与 管理 容器 ， 那 么 是 否 也 需要 类 似 于 LXC 的 工具 呢 ? 答案 是 肯定 的 。 事 实 上 ，Docker 0.9.0 以 前 Docker 正 是 通过 LXC 这 套 工具 来 完成 底层 容器 的 创建 与 管理 ; 而 从 Docker 
0.9.0 开 始 Docker 优 先 选择 libcontainer 作 为 创建 以 及 管理 容器 的 工具 。Docker、libcontainer 以 及 LXC 在 Docker 架 构 中 的 关系 如 图 14-1 所 示 。 
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Docker 容 器 范畴 内 一 切 与 Linux 内 核 相关 的 技术 实现 ， 都 可 以 认为 是 通过 libcontainer 来 完成 的 。libcontainer 指 定 了 所 有 与 容器 相关 的 配置 信息 ， 首 先 自然 是 namespace 与 cgroup 信 息 ， 除 此 之 外 ， 
还 有 容器 的 网 络 栈 配置 信息 ， 当 然 ， 还 包括 容器 的 挂 载 点 配置 、 设 备 信息 等 。 为 实现 与 Linux 内 核 的 通信 ，libcontainer 还 包含 模块 netlink， 完 成 内 核 态 进程 与 用 户 态 进程 的 I|PC (进程 间 通 信 ) 等 。 


本 节 主 要 介绍 libcontainer 的 模块 组 成 与 各 模块 功能 ， 对 libcontainer 的 分 析 均 基于 libcontainer 1.2.0 版 本 。 


14.4 总 结 


开发 者 普遍 了 解 甚至 掌握 Docker， 却 往往 会 忽视 libcontainer 的 重要 性 。libcontainer 作 为 容器 技术 的 一 种 解决 方案 ， 很 好 地 衔接 了 Docker Daemon 这 个 管理 引擎 与 Linux 的 内 核 特 性 。 更 为 直接 的 评 
价 是 : Docker 的 运行 不 能 没有 libcontainer， 而 在 libcontainer 的 基础 上 ， 任 何 开 发 者 或 团队 都 可 以 开发 或 者 再 造 类 似 Docker 的 容器 管理 引擎 。 相 信 Docker 官 方 也 希望 更 多 开发 者 参与 libcontainer 的 维护 
工作 ， 并 努力 推动 其 发 展 ， 使 libcontainer 成 为 容器 技术 的 标准 ， 从 而 在 容器 市 场 上 占据 更 大 的 份额 。 


第 15 章 Swarm 架构 设计 与 实现 


15.1 引言 


Docker 自 诞生 以 来 ， 其 容器 特性 以 及 镜像 特性 给 DevOps 爱 好 者 带 来 了 诸多 方便 。 然 而 ， 在 很 长 的 一 段 时 间 内 ，Docker 只 能 在 单 宿 主机 上 运行 ， 其 跨 宿主 机 的 部 署 、 运 行 与 管理 能 力 颇 受 外 界 诉 病 。 跨 
宿主 机 能 力 的 薄弱 ， 直 接 导 致 Docker 容 器 与 宿主 机 的 紧 耦 合 ， 这 种 情况 下 ，Docker 容 器 的 灵活 性 很 难 令 人 满意 ， 容 器 的 迁移 、 分 组 等 都 成 为 很 难 实现 的 功能 点 。 


Swarm 是 Docker 公 司 在 2014 年 12 月 初 新 发 布 的 容器 管理 工具 。 和 Swarm 一 起 发 布 的 Docker 管 理工 具 还 有 Machine 以 及 Compose。 


Swarm 是 一 套 较为 简单 的 工具 ， 用 于 管理 Docker 集 群 ， 使 得 Docker 集 群 暴露 给 用 户 时 相当 于 一 个 虚拟 的 整体 。Swarm 使 用 标准 的 Docker API 接 口 作为 其 前 端 访问 入 口 ， 换 言 之 ， 各 种 形式 的 Docker 


Client (Go 语言 的 客户 端 、docker_py、docker 等 ) 均 可 以 直接 与 Swarm 通信 。Swarm 几 乎 全 部 用 Go 语言 来 完成 开发 ， 并 且 还 处 于 一 个 Alpha 版 本 。 然 而 ，Swarm 的 发 展 十 分 快速 ， 功 能 和 特性 的 变更 迭 
代 还 非常 频繁 。 因 此 ， 可 以 说 Swarm 还 不 推荐 用 于 生产 环境 中 ， 但 可 以 肯定 的 是 Swarm 是 一 项 很 有 前 途 的 技术 。 


Swarm 的 设计 初 囊 和 其 他 Docker 项 目 一 样 ， 遵 循 “batteries included but removable" 原则 。 笔 者 对 该 原则 的 理解 是 : batteries included 代 表 设 计 Swarm 时 ， 为 了 完全 体现 分 布 式 容器 集群 部 署 、 
运行 与 管理 功能 的 完整 性 ，Swarm 和 Docker 协 同 工 作 ，Swarm 内 部 包含 了 一 个 较为 简易 的 调度 模块 ， 以 达到 对 Docker 集 群 调度 管理 的 效果 ; "but removable” 意 味 着 Swarm 与 Docker 并 非 紧 看 合 ， 同 
时 Swarm 中 的 调度 模块 同样 可 以 定制 化 ， 用 户 可 以 按照 自己 的 需求 ， 将 其 蔡 换 为 更 为 强大 的 调度 模块 ， 如 Mesos 等 。 另 外 ， 这 套 管理 引擎 并 未 侵入 Docker 的 使 用 ， 这 套 机 制 也 为 其 他 容器 技术 的 集群 部 
署 、 运 行 与 管理 方式 提供 了 思路 。 


本 章 主 要 从 Swarm 0.2.0 源 码 的 角度 分 析 Swarm 的 架构 设计 与 实现 。 分 析 内 容 包含 以 下 三 个 步骤 : 


1) Swarm 架构 ; 
2) Swarm 命令 ; 


3) Swarm 运行 。 
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宿主 机 能 力 的 薄弱 ， 直 接 导致 Docker 容 器 与 宿主 机 的 紧 耦 合 ， 这 种 情况 下 ，Docker 容 器 的 灵活 性 很 难 令 人 满意 ， 容 器 的 迁移 、 分 组 等 都 成 为 很 难 实现 的 功能 点 。 


Swarm 是 Docker 公 司 在 2014 年 12 月 初 新 发 布 的 容器 管理 工具 。 和 Swarm 一 起 发 布 的 Docker 管 理工 具 还 有 Machine 以 及 Compose。 
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本 章 主 要 从 Swarm 0.2.0 源 码 的 角度 分 析 Swarm 的 架构 设计 与 实现 。 分 析 内 容 包含 以 下 三 个 步骤 : 


1) Swarm 架构 ; 
2) Swarm 命令 ; 


3) Swarm 运行 。 


15.2 Swarm 架构 


Swarm 作为 一 个 管理 Docker 集 群 的 工具 ， 我 们 必须 首先 将 其 部 署 于 某 一 节点 。Swarm 的 部 署 形式 比较 丰富 ， 我 们 可 以 将 其 部 署 于 物理 服务 器 上 ， 也 可 以 将 其 部 署 于 虚拟 机 中 ， 还 可 以 将 其 部 署 在 
Docker 容 器 中 。 


由 于 Swarm 用 于 管理 Docker 集 群 ， 因 此 我 们 自然 需要 一 个 或 者 多 个 Docker 集 群 ， 集 群 中 每 一 个 节点 均 安 装 并 运行 着 Docker。 有 具体 的 Swarm 架构 如 图 15-1 所 示 。 
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15-1. Swarm 架构 


Swarm 架构 中 最 主要 的 计算 部 分 是 Swarm 节点 ，Swarm 管 理 的 对 象 自 然 是 Docker Cluster, Docker Cluster 由 多 个 Docker Node 组 成 ， 而 负责 给 Swarm 发 送 请 求 的 是 Docker Client, HAT 
言 ，Swarm 与 Docker 一 样 ， 也 是 C/S 架 构 ，Client 为 Docker Client，Server 是 Swarm 进程 。 以 下 主要 介绍 Swarm Node, Docker Node, node discovery 以 及 scheduler 这 4 个 重要 的 概念 。 


15.3 Swarm 命令 


通过 Swarm 架构 图 ， 大 家 可 以 对 Swarm 有 一 个 初步 的 认识 ， 比 如 Swarm 的 具体 工作 流程 : Docker Client 发 送 请 求 给 Swarm; Swarm 处 理 请 求 并 发 送 至 相应 的 Docker Node; Docker Node 执 行 相应 
的 操作 并 返回 响应 。 除 此 之 外 ，Swarm 的 工作 原理 依然 还 不 够 明了 。 


深入 理解 Swarm 的 工作 原理 ， 可 以 先 从 Swarm 提供 的 命令 入 手 。Swarm 命 令 主要 有 4 个 : swarm create、swarm manage、swarm join、swarm list。 当 然 ， 还 有 一 个 swarm help 命 令 ， 该 命令 有 助 
于 正确 使 用 swarm 命 令 ， 本 章 不 再 效 述 。 


154 ”总结 


Swarm 的 架构 以 及 命令 并 不 复杂 ， 本 章 初 步 介 绍 了 Swarm、Swarm 架 构 的 设计 与 实现 以 及 Swarm 命令 ， 希 望 能 为 学 习 Docker 集 群 化 管理 的 Docker 爱 好 者 带 来 帮助 。 


俗话 说 得 好 ， 没 有 一 种 一 劳 永 逸 的 工具 ， 有 效 地 管理 Docker 集 群 同样 也 是 如 此 。 脱 离 场景 来 谈论 Swarm 的 价值 ， 意 义 并 不 会 很 大 。 相 反 ， 探 索 和 挖掘 Swarm 的 特点 与 功能 ， 并 为 Docker 集 群 的 管理 提 
供 一 种 可 选 的 方案 ， 则 是 Docker 爱 好 者 更 应 该 参与 的 事 。 
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2014 年 12 月 ，Docker 官 方 在 荷兰 举办 的 DockerCon 大 会 上 宣布 推出 Docker Machine。 此 举 预示 着 Docker 从 原先 的 单机 部 署 迈 向 集群 部 署 ，Docker 生 态 圈 的 能 力 更 上 一 层 楼 。 


Docker 毕 竟 还 是 一 个 正在 飞速 成 长 的 项 目 ， 尽 管 存在 瑕 病 ， 但 是 Docker 在 单机 上 的 能 力 已 经 征服 大 量 优秀 的 开发 者 。 随 着 数 十 年 来 分 布 式 系统 的 发 展 ， 分 布 式 领域 同样 对 Docker 有 着 非常 强烈 的 诉 
求 。 如 何在 服务 器 上 自动 化 部 署 Docker， 如 何 跨 宿主 机 部 署 ， 如 何 使 Docker 的 部 署 适应 不 同 的 基础 设施 环境 ， 都 会 是 Docker 在 分 布 式 生产 环境 中 落地 时 必须 考虑 的 因素 。 


正 是 在 如 此 背景 下 ，Machine 应 运 而 生 。Machine 使 得 Docker 的 部 署 异 常 简易 ， 不 论 是 用 户 的 单个 主机 ， 还 是 用 户 的 数据 中 心 ， 以 及 可 能 是 第 三 方 云 平台 提供 商 提供 的 云 主机 。Machine 可 以 帮助 用 
户 在 运行 环境 中 创建 虚拟 机 服务 节点 ， 在 虚拟 机 中 安装 并 配置 Docker， 最 终 帮 助 用 户 配 置 Docker Client， 使 得 Docker Client 有 能 力 与 虚拟 机 中 的 Docker 建 立 通信 。 


一 个 大 型 的 分 布 式 环境 中 ，Docker 集 群 的 从 无 到 有 ，Machine 甚 至 可 以 一 键 完 成 ， 这 无 疑 将 大 大 节省 运 维 团队 的 人 力 、 物 力 。 同 时 ，Machine 完 全 有 能 力 适 应 多 种 不 同 的 底层 基础 设施 ， 如 
OpenStack, VirtualBox, Amazon EC2、Azure、Rackspace、DigitalOcean、SoftLayer、Hyper-V 等 一 系列 国际 知名 基础 设施 提供 平台 。 另 外 ， 通 过 Machine 创 建 的 虚拟 机 ， 不 仅 已 经 完成 Docker 的 
安装 与 配置 ， 同 时 还 可 以 保证 环境 中 所 有 Docker 配 置 的 一 致 性 。 只 要 是 通过 Machine 创 建 并 部 署 的 Docker 节 点 ，Machine 就 能 对 其 进行 远程 管理 或 者 执行 Docker 命 令 。 


全 球 范围 内 ， 随 着 基础 设施 即 服务 (laas) 越 来 越 完 善 以 及 Docker 的 逐渐 成 熟 ， 大 型 分 布 式 环境 中 Docker 的 集群 化 部 署 与 配置 ， 是 一 个 必须 攻克 的 问题 。Machine 作 为 Docker 官 方 推荐 的 部 署 工 


深度 关注 与 学 习 Machine 将 变 得 意义 重大 。 
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深度 关注 与 学 习 Machine 将 变 得 意义 重大 。 


16.2 ”Machine 架 构 


Machine 可 以 帮助 用 户 通过 一 条 命令 ， 从 零 开 始 ， 在 极 短 的 时 间 内 ， 拥 抱 Docker。 为 实现 此 目标 ， 用 户 需要 准备 一 些 前 提 条 件 ， 如 安装 Machine 软 件 (docker-machine) 、 提 供 第 三 方 的 虚拟 机 、 提 
供 软件 或 基础 设施 平台 。 


Machine 软 件 可 以 通过 下 载 二 进 制 文件 获取 ，Docker 官 方 的 下 载 地 址 为 : http://docs.docker.com/machine/。 官 方 提供 的 版 本 可 以 支持 三 种 操作 系统 ， 即 Windows、OSX 以 及 Linux。 除 此 之 外 ,用 
户 可 以 通过 编译 Machine 的 源码 生成 Machine 二 进 制 文件 ，Machine 的 源 代码 完全 托管 于 Github， 地 址 为 https://github.com/docker/machine。 目 前 ，Machine 仍 然 处 于 Beta 版 本 ， 功 能 以 及 特性 都 还 
在 不 断 地 变化 中 ， 因 此 Docker 官 方 暂时 还 不 建议 将 Machine 运 用 于 生产 环境 。Machine 的 版 本 更 新 非常 迅速 ， 本 章 以 Machine v0.2.0 为 例 ， 分 析 Machine 的 架构 以 及 实现 。 


Machine 的 架构 设计 如 图 16-1 所 示 。 
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16-1 Machine 架 构图 


并 非 如 Docker 一 般 ，Machine 不 是 一 个 Client/Server 架 构 。| 
统 都 会 创建 一 个 相应 进程 来 完成 


Machine 时 ， 后 台 并 非 是 一 个 常 驻 的 服务 进程 。 实 际 情况 下 ， 每 次 docker-machine 命 令 被 触发 时 ， 系 
用 户 指定 的 任务 ， 任 务 完成 后 进程 随即 退出 。 由 于 Machine 并 没有 后 台 进 程 ， 故 通过 内 存 来 存储 数据 的 方式 也 将 行 不 通 ， 此 时 Machine 将 所 有 创建 的 虚拟 机 信息 以 及 Docker 
信息 持久 化 至 宿主 机 文件 系统 中 。 


户 通过 docker-machine 命 令 使 


为 了 更 好 地 理解 Machine 的 架构 ， 首 先 我 们 来 认识 Machine 中 的 几 个 重要 的 概念 : Machine、Store、Host、Driver 以 及 Provisioner。 


16.3 ” Machine 与 Swarm 的 结合 


Machine 在 Docker 体 系 中 的 作用 


是 : 创建 装 有 Docker 的 虚拟 机 。 通 过 Machine 强 大 的 部 署 能 力 ， 我 们 并 不 能 很 好 地 调度 和 管理 Docker 集 群 。 而 Swarm 的 作用 
度 ， 若 能 将 Machine 与 Swarm 有 效 结合 ， 必 能 为 Docker 集 群 的 管理 人 员 划 


来 巨大 的 便利 。 
Machine 的 设计 理念 则 充分 考虑 了 这 一 点 。 只 要 


正 是 为 Docker 集 群 进行 有 效 的 管理 与 调 


FA, 来 管理 其 余 的 Docker Node, 


当然 ，Machine 也 可 以 在 安装 Docker 时 ， 启 动 一 个 Swarm Agent 容 器 ， 并 将 Docker Daemon 作 为 一 个 Docker Node 注 册 到 指定 的 Swarm Master 中 ， 便 于 Swarm Master 后 续 对 于 该 Docker Node 的 调 
Æ. Swarm Master 并 未 直接 运行 在 虚拟 机 中 ， 而 是 运行 在 Docker 容 器 中 。Machine 与 Swarm 的 关系 如 图 16-3 所 示 。 
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关于 如 何在 虚拟 机 上 安装 并 配置 Docker，16.2 节 已 经 讲述 得 较为 清晰 。 事 实 上 ，Swarm 的 引入 完全 是 在 此 基础 上 完成 的 。 由 于 Swarm 的 运行 环境 为 Docker 容 器 ， 故 Swarm 的 启动 离 不 开 Docker。 实 
际 运 行 过 程 也 是 如 此 ， 若 用 户 指定 安装 Swarm， 则 Machine 首 先 通过 Provisioner 在 虚拟 机 中 安装 Docker， 并 在 Provisioner 安 装 与 配置 的 最 后 一 个 步骤 执行 configureSwarm， 完 成 Swarm 的 启动 。 


若 需要 配置 Swarm， 不 论 是 Swarm Master 还 是 Swarm Agent， 用 户 均 需 在 执行 docker-machine create 命 令 时 传 入 相应 的 参数 。 


首先 来 看 Swarm Master 的 配置 流程 。Docker 安 装 完毕 之 后 ，Machine 中 的 Porvisioner 模 块根 据 用 户 的 需求 ， 需 要 在 虚拟 机 上 配置 Swarm Master， 故 Provisioner 通 过 SSH 连 接 至 虚拟 机 中 ， 并 执行 
docker pull swarm: latest 请 求 ， 用 于 下 载 swarm 镜 像 。 值 得 一 提 的 是 ，swarm 镜 像 不 仅 可 以 用 来 启动 Swarm Master， 同 样 可 以 用 来 启动 Swarm Agent。 由 于 用 户 指定 启动 Swarm Master, 故 
Provisioner 又 执行 docker run swarm: latest manage.…… 命 令 ， 直 接 启动 Swarm Master， 并 管理 传 入 的 Docker Node, 


一 般 而 言 ， 一 旦 用 户 要 求 配置 Swarm， 不 论 配 置 Swarm Master 还 是 Swarm Agent， 虚 拟 机 都 会 配置 Swarm Agent， 并 受到 Swarm Master 的 管理 。 如 此 一 来 ， 会 出 现 Swarm Master 与 Swarm 
Agent 处 于 同一 个 Docker Node 上 ， 而 这 种 情况 其 实 并 不 矛盾 ，Swarm Master 也 可 以 很 好 地 管理 自身 所 在 的 Docker Daemon。 对 于 Swarm Agent 的 配置 ，Provisioner 则 执行 docker run swarm: 
latest join.…… 命 令 ， 使 得 Swarm Agent 注 册 到 指定 的 Swarm Master, 


Swarm Master 与 Swarm Agent 的 配置 完毕 ， 则 意味 着 Swarm 集群 的 成 功 创建 。Machine 的 存在 很 大 程度 上 降低 了 用 户 与 基础 设施 打交道 的 成 本 ， 从 0 到 1 快速 创建 Swarm 集群 。 


164 总 结 


面 对 大 型 分 布 式 环境 或 者 尚未 利用 的 基础 设施 ， 如 何 快速 、 有 效 、 方 便 地 使 用 Docker， 已 经 不 再 是 一 个 脱离 现实 的 问题 。 某 种 程度 上 讲 ，Machine 的 诞生 使 得 Docker 技 术 的 普及 超越 了 开发 者 的 单 
模式 ， 更 是 为 中 大 型 企业 大 规模 运用 Docker 提 供 了 可 能 性 。 
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然而 ， 对 于 不 同 的 场景 ，Machine 的 价值 也 不 尽 相 同 ， 快 速 创 建 Docker 并 分 发 虚拟 机 的 模式 ， 在 大 规模 的 开发 环境 下 ， 能 为 开发 者 带 来 很 大 的 价值 。Machine 与 Swarm 甚至 其 他 容器 调度 引擎 的 结 
合 ， 更 是 为 大 规模 集群 的 管理 与 调度 提供 了 莫大 的 参考 价值 。 另 外 ，Machine 对 多 基础 设施 的 支持 ， 同 样 大 大 降低 了 云 平 台 迁 移 的 难度 ， 为 混合 云 的 发 展 ， 提 供 强 有 力 的 事实 依据 。 


第 17 章 ”Compose 架 构 设计 与 实现 


17.1 引言 


众所周知 ， 随 着 不 断 地 发 展 与 完善 ，Docker 的 API 接 口 变 得 越 来 越 多 。 尤 其 在 容器 参数 的 配置 方面 ， 功 能 的 完善 势必 造成 参数 列表 的 增长 。 若 在 Docker 的 范畴 内 管理 容器 ， 则 唯一 的 途径 是 使 
Docker Client。 而 Docker Client 最 原生 的 使 用 方式 是 : 利用 docker 二 进 制 文件 发 送 命令 行 命令 。 一 些 特殊 的 应 用 场景 下 ， 容 器 管理 过 程 的 配置 项 极为 元 长 ， 甚 至 很 可 能 是 多 容器 的 环境 。 因 此 ， 通 过 命令 
行 来 完成 容器 管理 显然 不 是 长 久之 计 。 很 长 一 段 时 间 内 ， 全 球 的 Docker 爱 好 者 都 在 探索 以 及 寻找 方便 容器 部 署 的 途径 。 


Docker 诞 生 于 2013 年 3 月 ， 同 年 12 月 ， 基 于 Docker 容 器 的 部 署 工 具 Fig 隆 重 登 场 。 在 Docker 生 态 圈 中 ， 经 过 了 两 年 多 的 洗礼 ，Fig 项 目 得 到 飞速 发 展 的 同时 ， 背 后 的 东家 也 发 生 了 很 大 的 变化 。 作 为 


Docker 界 容器 自动 化 部 署 工 
2014 年 7 月 双方 爆 出 新 闻 : Docker 收 购 Fig。 收 购 完成 之 后 ，Fig 改 名 为 Compose， 


的 翘楚 ，Fig 原 本 是 英国 伦敦 一 家 创业 型 公司 的 产品 。 


随 着 产品 的 发 展 ，Fig 的 巨大 潜力 受到 工业 界 的 普遍 认可 ， 在 不 到 一 : 


命令 改 为 docker-compose。 


第 17 章 Compose 架 构 设计 与 实现 


17.1 


引言 


众所周知 ， 随 着 不 断 地 发 展 与 完善 ，Docker 的 API 接 口 变 得 越 来 越 多 。 尤 其 在 容器 参数 的 配置 方面 ， 功 能 的 完善 势必 造成 参数 列表 的 增长 。 若 在 Docker 的 范畴 内 管理 容器 ， 则 唯一 的 途径 是 使 
Docker Client。 而 Docker Client 最 原生 的 使 用 方式 是 : 利用 docker 二 进 制 文件 发 送 命令 行 命令 。 i 


F 的 时 间 内 就 受到 Docker 公 司 的 密切 关注 。 很 快 就 在 


一 些 特殊 的 应 


行 来 完成 容器 管理 显然 不 是 长 久之 计 。 很 长 一 段 时 间 内 ， 全 球 的 Docker 爱 好 者 都 在 探索 以 及 寻找 方便 容器 部 署 的 途径 。 


场景 下 ， 容 器 管理 过 程 的 配置 项 极为 见长 ， 甚 至 很 可 能 是 多 容器 的 环境 。 


因此 ， 通 过 命令 


Docker 诞 生 于 2013 年 3 月 ， 同 年 12 月 ， 基 于 Docker 容 器 的 部 署 工 具 Fig 隆 重 登场 。 在 Docker 生 态 圈 中 ， 经 过 了 两 年 多 的 洗礼 ，Fig 项 


得 到 飞速 发 


展 的 同时 ， 背 后 的 东家 也 发 生 了 很 大 的 变化 。 作 为 


Docker 界 容器 自动 化 部 署 工 
2014 年 7 月 双方 爆 出 新 闻 : Docker 收 购 Fig。 收 购 完 成 之 后 ，Fig 改 名 为 Compose， 


17.2 Compose 介 绍 


的 翘楚 ，Fig 原 本 是 英国 伦敦 一 家 创业 型 公司 的 产品 。 


随 着 产品 的 发 展 ，Fig 的 巨大 潜力 受到 工业 界 的 普遍 认可 ， 在 不 到 一 : 


命令 改 为 docker-compose。 


的 时 间 内 就 受到 Docker 公 司 的 密切 关注 。 很 快 就 在 


探听 Fig 与 Compose 的 前 世 今 生 之 后 ， 让 我 们 回 到 Compose 本 身 ， 尝 试 挖 所 Compose 如 何在 Docker 乱 世 中 妾 露头 角 ， 尝 斌 分析 Compose 的 技术 以 及 定位 又 是 如 何 。 


认识 一 样 新 事物 ， 从 新 事物 的 作 
其 是 docker run 命 令 ， 一旦 参数 数量 骤 增 ， 通 过 命令 行 终端 来 配置 容器 较为 耗 时 ， 
通过 简短 有 效 的 docker-compose 命 令 管理 该 配置 文件 ， 完 成 Docker 容 器 的 部 署 。 


入 手 ， 往 往 不 会 出 太 大 差错 。 而 Compose 最 大 的 作 F 


b 


， 就 是 帮 


户 缓解 甚至 解决 容器 部 署 的 复杂 性 。 最 原始 的 情况 下 ， 通 过 Docker Client 发 送 容器 管理 请 求 ， 尤 
同时 容错 性 较 差 ， 且 修复 错误 命令 的 时 间 成 本 很 高 。Compose 则 将 所 有 容器 参数 通过 精简 的 配置 文件 来 存储 ， 


户 最 终 


编辑 配置 文件 与 编辑 命令 行 命令 的 难 易 程度 高 下 立 判 。 同 时 配置 文件 数据 的 结构 化 程度 越 高 ， 可 读 性 也 会 越 强 。 传 统 情况 下 ， 如 docker run 等 命令 的 参数 数量 很 多 时 ， 由 于 flag 参 数 的 书写 格式 各 异 ， 


很 容易 造成 


户 费解 的 情况 ;而 配置 文件 中 一 行内 容 就 是 一 类 具体 的 参数 值 ， 可 读 性 大 大 增强 。 


在 生产 环境 下 ，Docker Client 还 有 一 方面 经 常 被 Docker 爱 好 者 所 诉 病 ， 那 就 是 难以 进行 多 容器 的 管理 ， 每 次 管理 的 容器 对 象 最 多 只 能 是 


间 会 存在 逻辑 关系 ， 如 容器 A 使 
高 部 署 效 率 。 


诱 人 的 功能 与 软件 的 完美 之 间 ， 往 往 不 能 画 等 号 ，Compose 同 样 如 此 。 毕 竟 Compose 的 调 


容器 B 的 data volume， 如 容器 C 需 要 对 容器 D 执 行 link 操 作 等 。 对 了 


TT. 


对 象 为 Docker， 故 Docker 的 发 展 将 直接 影响 到 Compose 的 未 来 。Docker 尚 


该 工 


途 论 Compose， 因 此 Docker 官 方 并 不 建议 Compose 爱 好 者 在 生产 环境 中 使 


本 质 ， 自 然 也 会 深 陷 


。 除 此 之 外 ，Compose 本 身 也 存在 一 些 缺陷 ， 不 熟悉 


Compose 软 件 的 开发 绝 大 部 分 通过 Python 语言 完成 ， 而 本 章 的 分 析 均 基于 Compose 1.2.0 版 本 。 


17.3 Compose 架 构 


Dockers, Compose Ah ERMEL. 


4 
径 、 


ports: 
- "8000:8000" 
db: 
image: postgres 


映射 到 容器 内 部 的 8000 端 口 。 服 务 db 通过 镜像 postgres 来 创建 。 


容器 虽然 运行 时 相对 非常 独立 ， 但 是 很 多 情况 下 ， 容 器 之 
有 逻辑 关联 的 容器 ， 如 果 能 将 其 作为 一 个 整体 ， 被 工 


统一 化 管理 ， 那 将 大 大 减少 


户 的 人 为 参与 ， 提 


还 没有 达到 完美 的 地 方 ， 更 
中 ， 难 以 脱身 。 


的 角色 。 用 户 使 用 Compose 时 ， 首 先 需要 将 部 署 意图 通过 配置 文件 的 形式 交 给 Compose。 这 样 的 配置 需求 包括 : 容器 的 服务 名 、 容 器 镜像 的 build 路 
容器 运行 环境 的 配置 等 。 以 下 是 一 个 较为 简单 的 Compose 配 置 文 件 。 此 配置 文件 定义 了 两 个 服务 ， 名 称 分 别 为 web 以 及 db。 服 务 web 的 镜像 可 以 通过 docker build 来 构建 ，Dockerfile 所 处 目录 为 该 配 
文件 当前 目录 ; 服务 web 需 要 对 db 服务 进行 link 操 作 ; 最 终 服 务 web 将 宿主 机 上 的 8000 端 


配置 文件 在 Compose 体 系 中 不 可 或 缺 。Fig 时 代 支 持 的 配置 文件 名 为 fig.yml 以 及 fig.yaml; 为 了 兼容 遗留 的 Fig 化 配置 ， 目 前 Compose 支 持 的 配置 文件 类 型 非常 丰富 ， 主 要 有 以 下 5 种 : fig.yml、 


户 


fig.yaml、docker-compose.yml、docker-compose.yamll 以 及 上 


旨 定 的 配置 文件 路 径 。 


配置 文件 的 存在 为 Compose 提 供 了 容器 服务 的 配置 信息 ， 在 | 


基础 上 ，Compose 通 过 不 同 的 命令 类 型 ， 将 , 


户 的 docker-composer 命 令 请 求 分 发 到 不 同 的 处 理 方法 进行 相应 的 处 理 。 


户 docker- 


compose 的 命令 类 型 有 很 多 ， 如 命令 请 求 docker-compose up.…… 的 类 型 为 up 请 求 ，Compose 将 up 请 求 分 发 至 隶属 于 up 的 处 理 方法 来 处 理 ; 命令 请 求 docker-compose run.…… 的 类 型 为 run，Compose 


将 run 请 求 分 发 至 隶属 于 run 的 处 理 方法 来 处 理 。 


对 于 不 同 的 doc 不 同 的 处 理 方 法 来 处 理 。 


er-compose 请 求 ，Compose 将 调 有 


接 ， 并 在 该 连接 之 上 完成 Docker 的 API 请 求 。 事 实 上 ，Compose 借 助 docker-py 来 完成 此 任务 。docker-py 是 一 个 使 


Python 开发 并 调 有 


docker-py 作 为 Docker 官 方 的 一 个 Python 软件 包 ， 和 Docker 并 不 隶属 村 
Daemon 原 生 支持 的 API 接 口 此 ， 当 使 用 docker-py 作 为 Docker Client 访 
中 ，Compose 也 并 没有 对 其 进行 百分之百 的 实现 ， 而 这 主要 受 限 了 


同一 个 项 


少 。 


清楚 Compose 的 配置 文件 、 处 理 方法 以 及 docker-py 概 念 之 后 


' 


再 来 分 析 Compose 的 架构 ， 如 图 17-1 所 示 。 


由 于 最 终 的 处 理 必须 落实 到 Docker Daemon 对 容器 的 部 署 与 管理 上 ， 故 Compose 最 终 必 须 与 Docker Daemon 建 立 连 
Docker DaemonAPI 的 Docker Client 包 。 需 要 说 明 的 是 ， 
因此 docker-py 在 很 多 方面 的 发 展 均 会 滞后 于 Docker， 即 理论 上 而 言 ，docker-py 支 持 的 API 接 口 理论 上 会 比 Docker 
问 Docker Daemon 时， 确定 API 版 本 的 支持 是 非常 有 必要 的 一 步 。 另 一 方面 ， 在 docker-py 支 持 的 Docker API 接 口 之 

Compose 自 身 的 软件 定位 。 


毕竟 


在 Compose 架 构 中 ， 我 们 可 以 发 现 三 个 新 的 部 分 ， 分 别 为 : project、service 以 及 container。 这 三 个 概念 均 为 Compose 抽 象 的 数据 类 型 ， 其 中 project 会 包含 service 以 及 container。 首 先 介绍 这 三 者 


的 意义 。 


project 代 表 用 户 需要 完成 的 一 个 项 目 。 何 为 项 目 ? Compose 的 一 个 配置 文件 可 以 解析 为 一 个 项 目 ， 即 Compose 通 过 分 析 指 定 配置 文件 ， 得 出 配置 文件 所 需 完成 的 所 有 容器 管理 与 部 署 操作 。 例 如 : 用 
户 在 当前 目录 下 执行 docker-compose up-d， 配 置 文件 为 当前 目录 下 的 配置 文件 docker-compose.yml， 命 令 请 求 类 型 为 up，-d 为 命令 参数 ， 对 于 配置 文件 中 的 内 容 ，Compose 会 将 其 解析 为 一 个 
project。 一 个 project 拥 有 特定 的 名 称 ， 并 且 包 含 多 个 或 一 个 service， 同 时 还 带 有 一 个 Docker Client。 


Service， 代 表 配 置 文件 中 的 每 一 项 服务 。 何 为 服务 ” 即 以 容器 为 粒度 ， 用 户 需 要 Compose 所 完成 的 任务 。 再 次 以 本 节 前 面 配 置 文件 为 例 ， 配 置 文件 中 共 包含 了 两 个 service， 第 一 个 名 为 web， 第 二 次 
名 为 db。 一 个 service 包 含 的 内 容 ， 无 非 是 用 户 对 服务 的 定义 。 定 义 一 个 服务 ， 可 以 为 服务 容器 指定 镜像 ， 设 定 构建 的 Dockerfile， 可 以 为 其 指定 link 的 其 他 容器 ， 还 可 以 为 其 指定 端口 的 映射 等 。 


Docker Container Docker Container Docker Container 
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docker client (docker-py) 
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service service service 


Compose dispatch 


docker-compose 


command 


图 17-1  Compose R44 


从 配置 文件 到 service， 实 现 了 用 户 语义 到 Compose 语 义 的 转换 。 虽 然 一 个 service 尽 可 能 详细 地 描述 了 一 个 容器 的 具体 信息 ， 但 是 Compose 并 一 定 必 须 在 service 之 上 管理 容器 ， 如 果 用 户 使 用 docker- 
compose pull db 命令 ， 则 仅仅 完成 db 服务 中 指定 镜像 的 下 载 。 除 此 之 外 ，Compose 的 service 还 可 以 映射 到 多 个 容器 ， 如 果 用 户 使 用 docker-compose scale web=3 命 令 ， 则 可 以 将 web 服 务 横向 扩展 到 
3 个 容器 。 


若 用 户 对 service 的 请 求 最 终 会 落实 到 一 个 具体 的 容器 上 ， 则 Compose 会 在 service 范 畴 内 创建 一 个 container 对 象 ， 完 成 对 具体 容器 的 管理 。container 对 象 初始 化 时 即 集成 了 service 的 Docker Client, 
最 终 容器 所 有 的 操作 ， 都 由 container 对 象 通过 调用 Docker Client 完 成 。 


读 到 这 里 ， 大 家 可 能 会 一 个 疑惑 : Compose 如 何 决策 所 有 service 的 执行 顺序 ? 如 果 Compose 一 味 按照 配置 文件 中 的 书写 顺序 来 完成 service 的 指定 任务 ， 显 然 会 出 现 一 些 不 可 避免 的 问题 。 假 设 多 个 
service 所 描述 的 容器 之 间 存 在 依赖 关系 ， 一 旦 配置 文件 中 的 顺序 与 实际 的 正常 启动 顺序 不 一 致 ， 必 将 导致 容器 启动 失败 。 若 在 配置 文件 中 容器 A 的 描述 位 于 容器 B 之 前 ， 而 容器 A 的 启动 又 依赖 于 容器 B， 此 
时 若 顺 序 执行 A、B，A 容 器 的 启动 必定 将 失败 ， 而 之 后 B 容 器 可 以 正常 启动 。 


一 般 而 言 ， 容 器 依赖 关系 会 存在 以 下 三 种 情况 : 存在 links 参 数 ， 容 器 的 启动 需要 链接 到 另 一 个 容器 ; 存在 volumes_ from 参数 ， 容 器 的 启动 需要 挂 载 另 一 个 容器 的 data volume; 存在 net 人 参数 ， 容 器 的 
启动 过 程 中 网 络 模式 采用 other container 模 式 ， 使 用 另 一 个 容器 的 网 络 栈 。 为 了 解决 这 些 问题 ， 对 于 用 户 的 某 些 请 求 ， 如 docker-compose up 等 ，Compose 在 解析 出 所 有 service 之 后 ， 需 要 根据 各 
service 的 定义 情况 ， 梳 理 出 所 有 的 依赖 关系 ， 并 最 终 以 一 个 没有 冲突 的 顺序 启动 所 有 的 service 容 器 。 当 然 ， 这 种 情况 无 法 应 对 环 式 依赖 。 


17.4 Compose 评 价 


Compose 的 存在 非常 好 地 缓解 了 用 户 部 署 与 管理 容器 的 痛 点 。 首 先 ，Compose 的 存在 使 得 用 户 无 须 再 录入 匈 长 的 命令 行 命令 ， 其 次 还 扩 宽 了 容器 的 部 署 范畴 : 从 命令 行 的 单 容器 部 署 到 Compose 的 多 
容器 部 署 。 


17.5 总结 


本 章 从 Compose 的 历史 与 定位 入 手 ， 随 后 简单 分 析 架 构 设计 与 内 部 实现 ， 最 后 评价 了 Compose 在 容器 部 署 方 面 的 能 力 。 


Compose 的 诞生 ， 并 不 是 为 了 解决 一 切 部 署 问题 。 如 果 信服 这 一 点 ， 那 么 研究 Compose 的 应 用 场景 就 变 得 极为 有 价值 。 什 么 样 的 场景 下 ， 可 以 借助 Compose 发 挥 自动 化 部 署 的 魅力 ， 什 么 样 的 场景 
下 ，Compose 并 不 能 满足 需求 ， 而 需要 用 户 自 行 开 发 工具 进行 部 署 与 管理 ， 才 是 在 Docker 容 器 部 署 与 管理 领域 值得 深究 的 话题 。Docker 生 态 圈 仍 需要 不 断 地 发 展 ， 在 容器 缺乏 部 署 工具 方面 ，Compose 
仍然 会 处 于 一 枝 独 秀 的 地 位 。 清 楚 Compose 的 原理 ， 对 于 Compose 的 运用 定 会 有 很 大 的 帮助 。 


